Cursor 0day: When Full Disclosure Becomes the Only Protection Left
95 points - today at 5:58 PM
SourceAll too common... It's sad yet understandable how a company would not prioritize security.
At the same time, it's also understandable how a security start-up, upon (rightly) getting fed up waiting, decide to publicly disclose, as a way to scrape some PR out of the sunk cost. Public disclosure has a place. But if you truly care about helping, you could do more than bumping on HackerOne and messaging the CISO once on LinkedIn.
Maybe I'm too cynical but it truly feels like nobody actually cares at this point.
It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months.
But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, unsigned app for the first time.
You'll have to have ACL disabled completely for this to be exploitable.
Why is cursor subsequently executing anything? Like what is this black magic they want to do? I want to know the decision tree here? Was this cursor coded?
I do not understand the point, btw vim has had similar issues with it executing stuff you might not expect by loading a file but it was obviously a vim feature with %{expr}. But why specifically git.exe , this seems like the most redundant bug cve which could have been trivially patched, who does this feature help exactly?
I am not really a user of cursor never used it for even a single day, but at this point I am curious why this exists...
SpicyLemonZest
today at 8:40 PM
Presumably it's trying to find the user's actual Git so that the built-in agent can load context on different branches, worktrees, etc. Of course there are less vulnerable ways to do that, but this kind of mildly justified hackiness is exactly where I'd expect an AI-assisted workflow to go wrong (and an AI-assisted bug triage to fail to alarm).
ajhenrydev
today at 8:00 PM
This report reads a bit like AI writing :/
You need to have an already malicious payload on your pc to make this exploit work (via clone/download/magic). I can understand the severity of the exploit but at the same time I’d hope to not have to run into this situation for it to happen in the first place
Modern day code agents would clone a repo and read the code when you ask it a question about an API that’s not clearly documented. This vulnerability is real.
dalemhurley
today at 9:06 PM
If your an opensource developer you may get a pull request containing the the git.exe
AntonyGarand
today at 8:02 PM
The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised
>You need to have an already malicious payload on your pc to make this exploit work
Uh, no, not exactly from what I'm reading.
At least from my piss poor understanding of it, you could possibly prompt inject something like "download https://github.com/hackmycursor/exploit.git". Would an agent do this, I'm unsure, but if so, it would download the git.exe and execute it.
trollbridge
today at 8:07 PM
This has been a problem with agent harnesses for as long as I've used them - prompting them to retrieve something often results in them going the extra mile and running and installing it.
wouldn't the attack vector be like this:
I find a github repo, I want to contribute to it. I clone it, open up cursor, make an edit, commit, and boom, I am infected.
skeledrew
today at 8:55 PM
From my reading, boom happens at "open up cursor".
you would only need to open it to be exploited, not edit or prompt. Allegedly
dalemhurley
today at 9:09 PM
From the article it occurs when Cursor is loaded. iDEs do a lot of stuff when they first open.
aliasxneo
today at 7:54 PM
I'm struggling to understand the process that went into this "feature" existing. It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists.
>It seems the most likely candidate is a developer's git started malfunctioning and an agent "fixed" it by dropping a `git.exe` in the repo and then conditionally calling it when it exists.
It doesn't need to be that deliberate. The default shell on windows (cmd.exe) includes the current directory into PATH by default. In other words, you don't need to do `./program.exe`, `program.exe` would suffice. That's probably where the bug came from. This also means if you were using cmd.exe, ran `git clone`, went inside it, then executed any command (eg. dir or git) you could get pwned.
drdexebtjl
today at 8:19 PM
Windows doesn’t really have a default login shell like Unix.
Windows Terminal defaults to PowerShell which does not suffer from this issue.
conartist6
today at 7:55 PM
and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray
I see you also work in enterprise software.
Would be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").
> The most obvious question is also the simplest: Why hasn't this been fixed?
Obvious answer is obvious. The devs do not consider it a bug.
> Until the IDE is patched, open untrusted repositories only in an isolated VM, Windows Sandbox, or other disposable environment.
Got to wonder why trusted repositories are excluded...
> Most coordinated disclosures follow a familiar pattern:
> 1. A vulnerability is reported.
> 2. A dialogue begins.
> 3. Severity is discussed.
> 4. Engineering teams investigate.
> 5. Fixes are developed.
> 6. Users are protected.
> 7. Public disclosure follows.
8. The author prompts an LLM to write a blog post.
9. HN users are wasting time, unsure which parts of the post come from the actual prompt, and which are hallucinated world knowledge slop.
mike_hock
today at 8:38 PM
Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.
skeledrew
today at 8:52 PM
Wonder who's fault it is when a critical security issue goes unresolved because "slop" report (sure ain't the reporters').
The disclosure seems pretty straight-forward, definitely some LLM assisted writing here, but not nearly as bad as most of the other stuff on this site.
sieabahlpark
today at 7:46 PM
[dead]