> 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.
The CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level.
In response, companies just aren't responding like they used to. I spoke at a cybersecurity conference In June and the overwhelming "vibe" on the floor and in the talks was that responsible disclosure was dead or dying, and public disclosure is the way forward. The Microsoft and Nightmare Eclipse situation was oft cited.
As someone on the company response side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to.
This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of producing a report in the first place. Automated triage systems should be possible, and realistically it's well within the capabilities of most companies to go further and actually automate the Red Team side of it and catch issues before they surface in the black box research. From what I've seen doing so should cost dramatically less in tokens than the bounty payouts do.
The problem is that security is woefully underfunded in most companies, so even an infosec organization that saw the deluge approaching from a distance may well not have had the resources to prep for it even if they knew exactly what actions they would take if they had them.
> I don't understand why there's such a lack of response on the Cursor side.
~~~To busy porting to their new rust-backed version of Bun to do anything boring like engineering, probably.~~~
EDIT:
My mistake, wrong owners. It's hard to keep these tools straight sometimes. Most of the LLM tooling and interfaces I've tried are heavy on the features but light on the engineering, and that seems to be the case here too.
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.
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.
The entire point of Cursor is to run autonomous coding agents. You are giving it a random untrusted repo, saying "hey it might have a virus, go crazy" and then getting mad that it caused harm?
Check (and double check and triple check) your sources. If a malicious executable made it to your computer it is already too late.
I’ve never got my head around how it’s apparently the done thing these days to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. I somewhat naively hope that this is because everyone is pushing single purpose VMs for that kind of install, but really I know better.
Training people (esp. what passes for non-techies on Linux) to regularly copy-paste into the terminal is massively riskier than "click this URL". Just for starters, consider how easily you can make a web-page where you highlight X to copy it, but instead Y is delivered to your clipboard. Then on execute it could even redraw the terminal to pretend you pasted X all along.
Also, there's a convention or social-contract that everyone who downloads 2.10 ought to get precisely the same thing. This provides a foundation for other facets of security, like "it must have an expected hash" or "it must validate as signed by this public key". Also investigative actions like discovering when something suspicious got added, or detecting that the installer is trying to access the internet when it really shouldn't be.
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.
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.
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.
It’s been known for decades that you should never put your current directory in your PATH. There are endless opportunities for vulnerabilities then. I learned this in college in the 80’s (by not following it and getting owned).
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.
Yeah, but you can easily mitigate it by searching for the real git in known system locations and using whatever you find there (or allowing the user to configure the path). I believe that's how VSCode does it
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?
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.
Hah, not trying to pass off as human. Just communicating with my fellow men in black ;)
To be as explicit as possible: whether disclosing this publicly actually did more good then harm is not that clear cut. Even if accounting for all the second order effects.
Regardless, as a business you'd still be compelled to publish, because you've already poured resources into this research, there's still a chance to gain something, and there is enough plausible deniability about your true priorities.
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...
- Ask cursor to summarize your existing repo to write you a nice readme
- Cursor opens repo
- Cursor looks at current code
- Because it's going above and beyond, it also wants to give you some metadata about the code (other branches for things in development, maybe previous tags as milestones, etc)
- To do that, it runs some git commands
Now the malicious behavior. I ask Cursor to evaluate some remote repo. It clones it down and then runs the git command from the working directory. However, if you just call "git ..." from the command line there is ambiguity about that. What if there's already a git file in the directory which windows thinks you want to execute?
This could happen with an untrusted repo. Or could happen from you switching branches to a compromised branch (which you wouldn't expect to immediately run some code).
Normal way to handle this is using fully qualified path names for things. E.g. instead of git ... you give the full path to system installed git. Annoying for humans to type but trivial for Cursor.
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).
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.
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.
Uh, I don't think people typically associate downloading a repository, and viewing the source, as being synonymous with activating a malicious payload. That is the bit that's concerning.
I'm also so tired of people groaning about AI writing, yes, it's annoying, but attack the message, not the messenger.
>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.
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.
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
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.
> 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.
The CVE process itself is broken. HackerOne and company VDPs are inundated with new reports of varying quality thanks to the advancements (I think) in agentic AI. It's allowed for both an increase in trash-tier low quality AND legitimately high quality reports. Since the same AI's are writing both, its almost impossible to distinguish between the two at a surface level.
In response, companies just aren't responding like they used to. I spoke at a cybersecurity conference In June and the overwhelming "vibe" on the floor and in the talks was that responsible disclosure was dead or dying, and public disclosure is the way forward. The Microsoft and Nightmare Eclipse situation was oft cited.
As someone on the company response side of the HackerOne brokenness, I can confirm that this effect is real but would also note that the difficulty of distinguishing is not as severe as all that, because the companies have access to the source code which the researchers do not typically have access to.
This means that the token cost of verifying any given HackerOne report is dramatically lower than the token cost of producing a report in the first place. Automated triage systems should be possible, and realistically it's well within the capabilities of most companies to go further and actually automate the Red Team side of it and catch issues before they surface in the black box research. From what I've seen doing so should cost dramatically less in tokens than the bounty payouts do.
The problem is that security is woefully underfunded in most companies, so even an infosec organization that saw the deluge approaching from a distance may well not have had the resources to prep for it even if they knew exactly what actions they would take if they had them.
> I don't understand why there's such a lack of response on the Cursor side.
Too busy being acquired by SpaceX?
It screams intentional to me.
> Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.
It's hard to vibe code security.
Perhaps its a intentional back door?
NSA/FBI puts a git.exe in GitHub for a target. Target pulls the repo and it executes the payload.
As Cursor is/was based on VS Code, does it happen in VS Code too?
It’s a thing in VSCode as well/has been a thing or things similar to it : https://www.threatlocker.com/blog/malicious-vs-code-tasks-js... (2026)
https://www.reddit.com/r/programming/comments/zes1co/visual_... (2022)
> I don't understand why there's such a lack of response on the Cursor side.
~~~To busy porting to their new rust-backed version of Bun to do anything boring like engineering, probably.~~~
EDIT:
My mistake, wrong owners. It's hard to keep these tools straight sometimes. Most of the LLM tooling and interfaces I've tried are heavy on the features but light on the engineering, and that seems to be the case here too.
...that's Anthropic?
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.
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.
The entire point of Cursor is to run autonomous coding agents. You are giving it a random untrusted repo, saying "hey it might have a virus, go crazy" and then getting mad that it caused harm?
Check (and double check and triple check) your sources. If a malicious executable made it to your computer it is already too late.
I’ve never got my head around how it’s apparently the done thing these days to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. I somewhat naively hope that this is because everyone is pushing single purpose VMs for that kind of install, but really I know better.
> to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software.
how is that different from the good old days of
Training people (esp. what passes for non-techies on Linux) to regularly copy-paste into the terminal is massively riskier than "click this URL". Just for starters, consider how easily you can make a web-page where you highlight X to copy it, but instead Y is delivered to your clipboard. Then on execute it could even redraw the terminal to pretend you pasted X all along.
Also, there's a convention or social-contract that everyone who downloads 2.10 ought to get precisely the same thing. This provides a foundation for other facets of security, like "it must have an expected hash" or "it must validate as signed by this public key". Also investigative actions like discovering when something suspicious got added, or detecting that the installer is trying to access the internet when it really shouldn't be.
How is it different from downloading and running the application itself from that website?
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.
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).
It’s Windows autorun all over again. What was old is new again.
Cloning a repo owns your computer. Is that something you expected?
This attack is exactly why IDE's have a concept of trusted and untrusted locations.
That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.
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.
I'd say checking out a malicious branch is in the same category as downloading a malicious attachment. By which I mean, it's kinda on you.
Downloading this attachement doesn't executes it. Checking out a branch in this case executes the file in the branch. Thats a big difference.
Bro thinks cloning a repo means you're already 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.
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.
Same thing happens if I have a:
1) PS1 that displays the current git branch
2) Include the current directory in my PATH
Should we file a high severity CVE with bash now?
It’s been known for decades that you should never put your current directory in your PATH. There are endless opportunities for vulnerabilities then. I learned this in college in the 80’s (by not following it and getting owned).
If bash placed the current directory in your PATH by default, then yes.
Could file a CVE with Microsoft then, cause thats kinda what cmd.exe is doing:
The last line would execute git.exe from the cloned repo, wouldn't it?Not with bash. If your distro is putting ./ into the path then that's absolutely a high severity CVE with your distro's config.
I would file a CVE for any program that places untrusted content into PATH and invokes non-fully qualified executable names - not for the shell.
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.
Yeah, but you can easily mitigate it by searching for the real git in known system locations and using whatever you find there (or allowing the user to configure the path). I believe that's how VSCode does it
Yes, but it's an old known security gotcha people developing for Wintendo have to guard against.
that sounds like Cursor has a bug and vuln on Windows to me
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?
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.
This comment is so weird. It is so vague to me and feels so off, like an alien from Men in Black trying to pass as a human.
How do they not truly care about helping? Also what sunk cost? What does that mean?
Hah, not trying to pass off as human. Just communicating with my fellow men in black ;)
To be as explicit as possible: whether disclosing this publicly actually did more good then harm is not that clear cut. Even if accounting for all the second order effects.
Regardless, as a business you'd still be compelled to publish, because you've already poured resources into this research, there's still a chance to gain something, and there is enough plausible deniability about your true priorities.
The 0 day vulnerability is actually a developer is using 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...
Here's a common workflow:
- Ask cursor to summarize your existing repo to write you a nice readme
- Cursor opens repo
- Cursor looks at current code
- Because it's going above and beyond, it also wants to give you some metadata about the code (other branches for things in development, maybe previous tags as milestones, etc)
- To do that, it runs some git commands
Now the malicious behavior. I ask Cursor to evaluate some remote repo. It clones it down and then runs the git command from the working directory. However, if you just call "git ..." from the command line there is ambiguity about that. What if there's already a git file in the directory which windows thinks you want to execute?
This could happen with an untrusted repo. Or could happen from you switching branches to a compromised branch (which you wouldn't expect to immediately run some code).
Normal way to handle this is using fully qualified path names for things. E.g. instead of git ... you give the full path to system installed git. Annoying for humans to type but trivial for Cursor.
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).
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.
Startups historically are not the most security oriented
The "why it isn't fixed yet" part is pretty simple to understand. They ran the numbers and found that the intersection of developers who:
- Use Windows
- Don't use WSL or any other abstraction, but build/run their code directly on Windows
- Routinely clone random untrusted repositories
is too small to matter. End of story.
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.
This is exactly why every AI agent should run in a sandbox.
The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised
It's curious the number of people here who can't link these two things.
Uh, I don't think people typically associate downloading a repository, and viewing the source, as being synonymous with activating a malicious payload. That is the bit that's concerning.
I'm also so tired of people groaning about AI writing, yes, it's annoying, but attack the message, not the messenger.
>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.
If your an opensource developer you may get a pull request containing the the git.exe
I think you’ve got it wrong; no malicious payload need be on your box already. That’s not what the article says.
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.
You can leave out cursor and it would do the same thing.
From my reading, boom happens at "open up cursor".
you would only need to open it to be exploited, not edit or prompt. Allegedly
From the article it occurs when Cursor is loaded. iDEs do a lot of stuff when they first open.
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.
Windows doesn’t really have a default login shell like Unix.
Windows Terminal defaults to PowerShell which does not suffer from this issue.
Windows has a default login shell which is explorer.exe.
Windows also has a system(const char*) which certainly does something.
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.
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.
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
Would be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").
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.
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?
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.).
I meant the attack would be the other way around- if an infected package had the git.exe file in their root.
Or, the infected package could also copy that file into the parent project's root.
Oh yeah that's a good point - two layers of auto executing scripts/binaries.
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.
Does the git lookup run before the trust check, or ignore it?
> 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.
> 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.
Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.
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.
Wonder who's fault it is when a critical security issue goes unresolved because "slop" report (sure ain't the reporters').
> 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...
Except it might come from a trusted repo. Some of the biggest repos have been recently targeted in supply chain attacks. Consider for a moment
1. Attacker takes over maintenance of a widely used Cursor extension
2. Attacker adds a remote backdoor to monitor which repos are being maintained
3. Attacker decides to only infect the largest one with a git commit hook
4. The developer didn’t even know they just included git.exe in their commit
5. The developer is a sole maintainer on the repo and merges their own PR without review (because they(/their AI) wrote it)
6. Now a trusted repo is infected
7. A contributor pulls down the infected repo and opens cursor