[reubenmorais]

It's an unfortunate incentive structure. If you're doing offensive security research, there's two ways you can go about it: you can report the potential vulnerability without exploiting it, in which case you risk the company coming back to you and saying "thanks but we don't consider this a vulnerability because it's only exploited through misconfiguration and we're too smart for that". Maybe you get some token reward of $50.

Or you can exploit it and say here's the PoC, this many people at your company fell for it, and this is some of the valuable data I got, including some tokens you'll have to rotate. This puts you into actual bug bounty territory. Certainly the PR side of things alone will incentivize them to pay you so you don't make too much of a noise about how Cursor leaked a bunch of credentials due to a misconfiguration that surely every good programmer knows about and defends against (like so many vulnerabilities seem so dumb in hindsight).

[xmodem]

Cursor does not have a bug bounty though, and its hard to see how this constitutes anything other than a direct attack on them, their users, or both. "The incentive structure made me do it" does not justify acting like a criminal.

[grajaganDev]

Cursor asks researchers to report vulnerabilities to their GitHub security page.

The same incentive to show impact applies even without a paid bounty.

[px43]

> Cursor does not have a bug bounty

Shouldn't this alone be considered criminal negligence at this point? Cursor isn't some random open source project. It's a company that has funding, and subscriptions. Hell, I pay Cursor for a monthly subscription. Pretty incredible that they have no bounty program.

[britannio]

The lack of a bug bounty program doesn't prohibit them from rewarding reported vulnerabilities.

[taskforcegemini]

do they though?

[miki123211]

You can also console.log those credentials as a PoC, and then show that the console.log could trivially be replaced by a fetch().

Kind of like a lot of exploit PoCs just "pop a calc" (AKA open the Calculator app), not because opening the calculator is valuable to an attacker, but because if you can open calculator, you can do anything.

[objectified]

The problem there though, is that with PoCs like this, as an attacker you want to have a ping back to your system so that you know the attack has been successful (in this case they probably expected/hoped someone at Cursor to install the package, that's the usual objective in a dependency confusion attack). But what they could have done, is send a less sensitive thing like just the current working directory or current effective user, instead of the whole environment.

[fkyoureadthedoc]

What actually changes though in your scenario? Potential bad actor gets RCE on your dev machines, it doesn't really matter what they sent home, you're rotating keys and doing your due diligence either way.

[mistercow]

I wonder how viable it would be to find a public key your target owns and use it to encrypt the data you send back. Then you could prove to them that you exfiltrated real data without exposing it to anyone outside the company.

Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””

[necovek]

HTTPS certificates should already have that public key for you, so it should be trivial.

[Szpadel]

wouldn't capturing only env names without values be ideal middle ground?

look we had access to your Aws tokens, we could take over your account but we didn't steal actual token, we just got proof that we could access it

[reubenmorais]

Yes I agree names only would have been a better approach here.

[6mile]

Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.

[mcherm]

> The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.

I don't actually think that is a bad thing.

The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.

The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.

[dagw]

The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns

They actually do have this. TSA seem to still suck at their job:

https://www.forbes.com/sites/michaelgoldstein/2017/11/09/tsa...

https://www.gao.gov/products/gao-19-374

[LtWorf]

You'd also suck if you knew your job is useless busywork.

[whimsicalism]

a prerequisite of “offensive security research” is that it is solicited, no ifs or buts.

what they did was absolutely wrong and frankly likely illegal

[peanut-walrus]

Yeah, it sucks, but that's the way it is. It is super common for bug bounty findings to be ignored or downgraded unless you show actual code exec on their machines or dump some of their creds.