I'm not sure I fully agree with this being a major vuln. There's a lot of up front scary text which was raising a lot of red flags until it actually discussed the "what".
An actor has to place a malicious .exe in the user's code folder, named git.exe, for this to take place.
I see this akin to something like saying "replacing their .bashrc with an alias that says `ls` instead executes `/tmp/mega-big-virus.sh` is a vuln".
Yes it's a vector, but if they've placed something in your filesystem like that already, you've already been compromised.
I am not at all a security expert, but isn't this akin to giving a repo-owner RCE if you just clone their repository and open it? I feel like that's not an implied contract for opening a folder in your IDE.
The user's code folder? You mean the code I frequently pull from untrusted sources, unlike my .bashrc? Opening a GitHub project for review should not mean arbitrary code execution.
Of course, that ship has long sailed, for all major IDEs. Heck, VSCode SSH and devcontainer remotes allow RCE by design.
This is very similar to 30yo exploit in which you placed an alternative, infected dll inside a folder with mp3s (winamp), or photos (windows picture viewer).
This doesn't require anyone placing anything deliberately on your machine (as in, needing to exploit it somehow ahead of time). It could be as simple as checking out a branch to review, where the author of the branch has added the .exe.
> The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor.
> The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.
Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.
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.
And what'll the prompt say? "Do you want to run git.exe?"? I'll probably assume Cursor needs to run git but permissions got messed up somewhere and click right through that.
I haven't used Windows in a while so pardon if I'm missing something.
This draws to mind the dialog that opens when you open a new project in Cursor (and VSCode too, I think), where the IDE asks the user if they trust the project they're opening. Is Cursor under the impression that this is sufficient security apparatus?
Since there are no approval dialogs, it sounds like that doesn't even come into play here. That is the "gate" (to use the AI parlance) that Microsoft places on code execution in workspaces, though, and I would expect Cursor to at minimum fix this to only execute git.exe in trusted workspaces.
I think this is slightly less of a Cursor bug than a bit of a Windows quirk: Windows searches the current working directory for executables before resorting to the path variable. I imagine a lot of stuff is vulnerable to such an "attack" on Windows.
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...
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).
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.
All 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.
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.
>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.
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.
It has nothing to do with npm. However, a binary could be configured to extract your git/npm secrets using this exploit, which could then lead to a npm supply chain attack (or pip, etc. etc.).
Frankly, if you git clone a compromised repository, I'm not sure that a vulnerability of the class "compromised code in that repository will be executed" is all that major a concern. There are plenty of IDEs that will go autonomously run npm installs (with post-install scripts) for you when they detect a package.json. This isn't all that different than that.
They could throw up a warning like "do you trust this repository" oh wait they already do, and no one cares. Security is hard. Ultimately if you have compromised code on your machine, all bets are off.
A lot of malware was delivered back in the day via Windows AutoPlay feature. Someone plugs a USB drive in and bam, they are immediately exploited. You could say it's always a problem if the USB drive is already full of malware. However, Microsoft disabled AutoPlay in Windows 7 (and backported this fix) specifically to address this vulnerability.
This exploit feels very similar to me. I don't know if there's a specific name for this classification of AutoPlay issues.
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.