Hey there! I run DevRel & SecRel @ Snyk, we just published a piece to help dispel all the rumors, etc. This provides a lot of in-depth info on the situation: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case.
Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions.
It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.
Who did the GDPR review before extracting env vars from systems that were not under your control? How did actively extracting potentially private data from the environment not get flagged as Unauthorized Access?
If this "experiment" (which happened to be against a competitor, mind) was reviewed and approved internally, that is a great demonstration of Snyk's approach to (ir)responsible data collection and disclosure.