- > 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.
by lemagedurage
0 subcomment
- The problem seems to be deeper rooted. Cursor doesn't see cloning a repo with Cursor and code execution as separate security boundaries.
Cursor ships with Workspace Trust disabled by default [0]. A repo that includes .vscode/tasks.json with "runOn": "folderOpen" will already run arbitrary code [1].
[0] https://cursor.com/docs/agent/security#workspace-trust
[1] https://www.oasis.security/blog/cursor-security-flaw
- As someone who is on the other side, the amount of familiar, LLM generated reports are overwhelming and usually falls under "not familiar with product design/security scope" category. But there are also really good ones - so I can't afford to not take actual look at each, but it gets tiring and we need a solution. Spamming the former category with LLM generated "rationale" isn't that solution (yes I can tell this article is mostly LLM generated).
Unfortunately, this looks like the former case. If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software. Unless cursor commit themselves to securing the user environment, which I don't think they are in the business of.
If you are generating a CVE report with LLM, please use LLM responsibly in helping you reproduce deterministically. Then please do the write up yourself, keep it as concise as possible and strip most adjectives in any LLM generated sections as they cannot help themselves to write without mostly useless exaggerations.
- 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.
- 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...
- 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.
- Given the fact that people frequently give their coding agents permission to pull and push from git, this is a massive vector for supply chain attack. Some cursor instance you left running on a project has an agent that wants to grab the latest project files, some attacker has compromised some project and put their exe into it and X00,000 of people are all of a sudden running random EXE as the primary user
- 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.
by ajhenrydev
7 subcomments
- 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
by dclowd9901
3 subcomments
- 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?
- Isn’t this a Windows flaw where it effectively treats the current directory as the head of the path? (I remember the naïve olden days of people’s Unix Path starting with .) Or is Cursor going out of its way to execute a git.exe in the current directory?
by aliasxneo
3 subcomments
- 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.
by hmokiguess
0 subcomment
- The 0 day vulnerability is actually a developer is using Windows
- This is exactly why Unix PATH (and offspring) does not contain "." by default. If you unpack an untrusted archive and run "ls" you could get popped.
Agents should be no different.
- 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.
by aniceperson
0 subcomment
- damn those ai written Blogs are tiring. o a single paragraph saying that "cursor o windows loads ./git.exe with higher precedence" would be enough.
- On Windows, if your shell was in a malicious repo's directory and you ran any "git" command, wouldn't the behavior be the same? Binaries in the current directory are considered before PATH. This seems like a broader issue.
That said, Cursor should at least have some "trust this directory?" dialogue.
- There's discussion whether this is a vuln. While some responsibility should be on the user to already having downloaded a malicious binary, I think it's poor default behavior from cursor to run git from the repo root. Is it really a use case to have git.exe in a git repo — more like a red flag.
- Wouldn't this be something a virus scanner would detect and quarantine?
Not an active Windows user, but I can't imagine any sane person working on Windows OS without malware protection.
- Has anyone tried to replicate this? I copied my calculator app and renamed it to git.exe, put it in a few repositories, openned cursor with those repositroies loaded, even prompted cursor to scan the repository, to which it said it saw the git.exe ("Accidental binary — delete it, don’t commit"), but nothing was executed to my knowledge
- I am not certain about Windows but on Linux, aren't applications supposed to use PATH based resolution provided by shell for this? Why go to the root of the project directory at all looking for binaries? Because it has been become their favorite place due to readme / skills etc being there?
- Clone a repo and run "npm install" and the exact same thing will happen. You can say "oh I would never run npm install on a repo I don't trust"...but then why are you cloning it and opening it in an IDE in the first place? Especially an IDE whose entire purpose is to run autonomous coding agents?
- > 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.
- I guess this is only specific to a file in the root of the repo, so it doesn't allow for an NPM supply chain attack?
- Isn't this the oldest kind of vulnerabilities corrected on UNIX several decades ago?
The current directory is not in the PATH, period.
This is also a bug on Windows only, so to me this is more a Windows issue than a Cursor issue, unless there's some logic in Windows that is doing the same as UNIX has done for decades. Given the "fix" involves ACL and a complex workaround that's not really a fix, I stay in my position this is more a Windows fuckup than something particular to Cursor.
- Crazy that 7 hours after this post there's no one from the Cursor team saying anything here. This is HN, your highest leverage audience, Anysphere... no one is home?
by vanyaland
1 subcomments
- Does the git lookup run before the trust check, or ignore it?
by throwitaway222
1 subcomments
- Uh, you're already beyond fucked if git.exe (or equivalent in *nix) is a hacked one and on your system. And similarly the same doomsday article does not exist for VSCode, Zed, GitKraken, and a billion other tools that run git without caring to ask..
- > 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...
by theaniketmaurya
0 subcomment
- First grok cli and now this
- 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.
by charcircuit
0 subcomment
- Suspiciously the authors do not say if this works in restricted mode. This is not considered a vulnerability outside of restricted mode.
- >This bug is simple. A developer opens a repository in Cursor on Windows, and if that repository contains a malicious git.exe in the project root,
A vuln that requires an existing malicious executable to have already been downloaded and have it executable bit set to true? Doesn't sound like a vuln
>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.
It's probably 3 factors:
- Lots of bounty begs powered by vibecoding. This gets lost in the noise (like this report)
- Cursor is itself vibecoded so they ship features faster than they care to fix issues.
- don't know if it's me or the way Mindgard is putting this, but it's presented as a critical bug, and upon reading it, it's very hard to see the subtle low priority security issue.
Here's a rough unbiased summary of the 'issue':
Cursor loads the 'git' dependency at runtime. If the user has downloaded a malicious repository, they will get pwned when they open cursor even if they don't run any prompts.
The author seems to suggest that either git should be looked for in the 'proper dependency' folder to mitigate this risk. This would mean that attackers would pwn the victim when a the user opens cursor and runs 1 prompt that executes a vulnerable file called runme.exe instead of being pwned just by the user opening cursor on the malicious repo.
by iririririr
0 subcomment
- this attack vector is part of the spec in all Java build systems.
you don't even need ai slop ide. Java Devs will happily execute your malicious maven/gradle/Grovy/whatever that you push to any public repo. bonus point ofy commit message is complaining about some build plugin version compatibility
- [flagged]
- [flagged]
by glasffordd
0 subcomment
- [dead]
- [flagged]
by sieabahlpark
0 subcomment
- [dead]
by fatmacelik6894
0 subcomment
- [flagged]
- Why do you guys write essays to justify doing the leak
Have you all drunk too much psyop koolaid?
Three things are obvious:
1 - “Responsible disclosure” by a unilaterally proscribed process only benefits an abuser
2 - The abuser sets a price for the disclosure that is arbitrary and parallel to its market value, the attractiveness is based solely on your vulnerability to how much the abuser can abuse you with the state
3 - The vulnerability’s continued existence isn't necessarily a breakdown of disclosure processes, it could literally be malice. congratulations you found the honeypot, it wont be confirmed by the state for 70 years
Hacker News