Rendered at 20:35:10 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
wxw 23 hours ago [-]
> 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.
app13 22 hours ago [-]
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.
demosthanos 21 hours ago [-]
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 the capacity.
20 hours ago [-]
QuadmasterXLII 20 hours ago [-]
The token cost of a report is lower bounded by the number of tokens in the report * price per token of the cheapest model. The token cost of a good report is much higher, but sifting out the good reports is the entire problem.
demosthanos 18 hours ago [-]
In theory, yes, but are you actually seeing clearly-garbage lower-bound reports like this?
The ones we're seeing show clear evidence of being AI-generated, are often incorrect or duplicated, but they also show clear evidence of the AI having done its homework and spent a while crawling our API.
Even if we were getting reports at the lower bound you're describing, those would be even easier to triage: just add a quick step to check if the API in question even exists, then if it does that very cheap "where is this API" query becomes part of the input to the second-level triage that spends more tokens.
infinite_spin 18 hours ago [-]
Do you have a tier based system for identifying high value reporters? Like a credit score for vulnerability hunters?
demosthanos 17 hours ago [-]
Not formally, but we do informally recognize names and prioritize researchers who reliably turn up good results.
infinite_spin 16 hours ago [-]
that might be a nice incentive for bounty hunters, a sign of recognition and a good metric for triage
tedivm 8 hours ago [-]
Their CISO literally acknowledged it and then they all continued ignoring it again. This isn't just bad process, this is a broken security organization.
sandeepkd 18 hours ago [-]
Should a company promoting the enterprise usability of AI, itself start with building a intake process to distinguish between the noise and signal for these reports. If you cant solve your own problems with your product then how do you expect the customers to be able to use it.
pseudohadamard 15 hours ago [-]
Not even that. Even before AI came along the widespread practice of CV-Enhancement was slowly strangling the reporting of actual legitimate, needs-to-be-fixed issues. When it turns into a giant shit-shovelling exercise it's not surprising that some of the shit doesn't get shovelled.
Not defending HackerOne, but pointing out that it's not a black-and-white issue.
sofixa 22 hours ago [-]
> 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.
koolba 20 hours ago [-]
Is it though? Cause you can have an agent analyze the reports to filter out the wheat from the chaff.
thayne 14 hours ago [-]
I suspect that is exactly what cursor did, and the agent (incorrectly) categorized this as chaff.
iainmerrick 8 hours ago [-]
Ideally, they’ll be able to look back through the logs and find the original analysis from when the bug was submitted, figure out why it was incorrectly filtered, and use that to improve their automation.
The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
petesergeant 15 hours ago [-]
> It's hard to vibe code security.
Conversely, running human or LLM-generated code through multiple LLMs to look for security holes is a fantastic way to increase security.
buran77 22 hours ago [-]
> I don't understand why there's such a lack of response on the Cursor side.
Too busy being acquired by SpaceX?
22 hours ago [-]
solid_fuel 22 hours ago [-]
[flagged]
manacit 22 hours ago [-]
...that's Anthropic?
_AzMoo 22 hours ago [-]
It screams intentional to me.
khurs 22 hours ago [-]
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?
I think those are both different in that they require the user to say they trust this code. Additionally the first is arguably not a bug (the code in tasks.json will indeed run if you say you trust the project) and the second was reported and fixed within two months.
oceansweep 17 hours ago [-]
Yes, my point was more so the underlying behavior of automatic execution of binaries associated with/inside of a git project exists already within vscode as a pattern, and so seeing cursor doing the same wouldn't be surprising.
lemagedurage 14 hours ago [-]
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].
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.
hack1312 14 hours ago [-]
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
romanovcode 14 hours ago [-]
We're back to autorun.exe times
username135 14 hours ago [-]
Time is a flat circle it seems
nicman23 10 hours ago [-]
but it is just a agents.md file lol
mort96 9 hours ago [-]
This has nothing to do with any language model or agent, this is just traditional deterministic code in the Cursor program.
himata4113 11 hours ago [-]
Let me introduce you to jetbrains, vscode and nearly every other IDE that relies on an LSP.
Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.
DanielHB 11 hours ago [-]
VSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.
hack1312 6 hours ago [-]
There’s no trust system by default in Cursor because they ship that feature disabled.
Both jetbrains and vscode ask you if you trust the project
nextweek2 9 hours ago [-]
It isn't "a binary", it's git.exe (which has a very specific purpose). We are talking about an AI tool which wants to know the current state of the folder it is indexing, that's a reasonable thing for an AI to want to do.
You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around since day one.
To me the App is preparing to do some work so it is more responsive to my requests. This is a classic trade off between security and performance, where the odds of a malicious virus being in the root of your project are very small if you are already taking best practices.
Perhaps what we really need is Microsoft to change the execution order and that the maintainers of Git add a new feature where we can block executables being in the root of a repo (or in the whole of a repo). That would prevent every app having to make the same workaround, fix the issue upstream and you'll never have to think about it again.
mort96 9 hours ago [-]
git.exe is just a name. Cursor has no reason what so ever to assume that a random binary in a random repo is a legitimate git binary just because its name happens to be git.exe.
wongarsu 8 hours ago [-]
The trivial fix is to execute not "git.exe" but "C:\Program Files\Git\bin\git.exe". With a configurable git binary
Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution
hughw 10 hours ago [-]
> 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.
What do you think PATH variables are for? Cursor just immediately adds the repo to your PATH, iiuc, without user approval.
f311a 13 hours ago [-]
> 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.
There is not easy solution, the landscape has changed and if care about security, you just need to allocate more human resources. Another layer of LLM checks won't help.
jjcm 23 hours ago [-]
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.
shitter 23 hours ago [-]
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.
paxys 21 hours ago [-]
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.
shitter 20 hours ago [-]
? Doesn’t the code exec happen upon merely launching Cursor against a repository, without giving an agent any tasks? That’s clearly an issue at the Cursor application level, not some inevitable risk caused by the non-deterministic nature of LLMs. You can’t use the latter fact to excuse the former mistake
Not to mention that Cursor has an agent permissions model that this presumably sidesteps!
cute_boi 17 hours ago [-]
I agree cursor can fix the issue, but the main issue is downloading anything from untrusted source. The repo may have AGENTS.md which can tell please install npm package from random repo and run pnpm start etc...
We should never ever download any pdf or excel macros etc.. from untrusted source.
hnfong 7 hours ago [-]
If we take your logic to the extreme, then there are never any legitimate code execution vulnerabilities in web browsers since the user is not supposed to visit untrusted websites.
iainmerrick 8 hours ago [-]
If you can’t download anything safely, the web can’t exist.
brookst 16 hours ago [-]
Different layers, different risks.
You do not expect an agent-level app to run untrusted binaries. You expect prompt injection, etc.
And I don't at all agree that a malicious executable landing in some directory is already game over. Plenty of zip files have malicious executables, it doesn't mean you say "oh, my zip extractor should just run every executable because if one's bad I'm already toast".
xeyownt 11 hours ago [-]
Ok, so you download the repo, launch Cursor, it compiles code and run it (if not, why do you even use Cursor at the first place?). Same effect.
thewhitetulip 19 hours ago [-]
Cursor is used for vibe coding. There are people who used Cursor to build a webapp where passwords are printed on the front page
So yeah, this is a major issue
preg_match 3 hours ago [-]
These days I run absolutely everything dev related inside of podman containers, no node or anything on my host. But even that's not enough, because the IDE support for that is lacking and those tools expect host binaries to be available. I can largely get around it with ro mounts and such but it's very annoying.
Containers are really good now, there's zero reason why every extension and LSP isn't containerized.
Also agents inside a container. It's very nice because I have zero trust for harness permission systems. But again, why aren't the tools designed from the ground up to be containerized?
taneq 22 hours ago [-]
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.
petalmind 21 hours ago [-]
> 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
wget ftp://ftp.something.org/software-2.10.tar.gz
tar zxfv
./configure
make
sudo make install
?
Terr_ 21 hours ago [-]
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.
loa_in_ 8 hours ago [-]
Agreed, don't train fellow human beings (users) to follow, educate them.
"Make things as simple as possible, but no simpler." - commonly known quote.
We're making things so simple, the users don't get to have a proper chance at learning what's happening. Training people away from giving programs access, makes it opaque and dangerous. Unfortunately at the same time for non technology inclined users even Windows approach of file->Properties->Security visual UI proves challenging.
mh- 19 hours ago [-]
> Then on execute it could even redraw the terminal to pretend you pasted X all along.
Diabolical idea. Anyone know if there's been anything in the wild that did this?
VTimofeenko 19 hours ago [-]
[dead]
uecker 15 hours ago [-]
Not much, and people also should not to do this. One should at least have a check of hash of the download vs some document signed with a key.
In any case, the curl|bash from a website is way worse as it leaves no trace. Here, you have an artifact, and multiple steps, so the probability that an issue can be detected is higher and when someone gets compromises one has a change to figure out what happened and warn others. (so good practice to copy the file somewhere else). People look at this only from purely "can I get compromised" perspective, but overlook this community aspect.
19 hours ago [-]
taneq 20 hours ago [-]
They’re both executing unknown code, but hopefully the ftp site here is at least a trusted one, and if you feel paranoid you can verify the archive’s hash to help verify it hasn’t been monkeyed with.
Also the archive probably won’t go and fetch a bunch of other scripts and run them (probably…) while doing so is usually the script’s primary purpose. So you’re not just trusting the people who published the script, at the time they published it. You’re trusting them and everyone they trust to still be good actors now.
That’s different to it being the standard way to install self-published bundles of scripts from all over the internet.
paxys 21 hours ago [-]
How is it different from downloading and running the application itself from that website?
xeyownt 11 hours ago [-]
The illusion of security.
mort96 18 hours ago [-]
The very first paragraph of text presented to the reader on the page start with:
After loading a project, Cursor attempts to find git binaries
at various locations including the current workspace.
By creating a repository with a planted malicious git.exe
in the root, the IDE will execute it with no user interaction
and no prompting of the user.
This is a remarkably straightforward 2 sentence explanation of the issue (the "what"). They're not exactly hiding it.
AndrewThrowaway 9 hours ago [-]
I clone some repo from github, open it with default code editor which happens to be Cursor. I am cooked. That is it.
It is the same as autorun.exe on some CD - I put some CD in my CD-ROM and my Windows are compromised.
You can argue that I should not clone unknown repos, I should inspect each and any file in the repo, look for git.exe or any other suspicious binary and etc. I should not put untrusted CDs or USB sticks into my computer.
However the reality of it is that it will not be the user who inspects USB stick in some contained environment, it will be security policy which disables autorun. Same as Cursor should disable this.
arcticfox 23 hours ago [-]
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.
zeroq 23 hours ago [-]
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).
datakan 22 hours ago [-]
It’s Windows autorun all over again. What was old is new again.
inigyou 21 hours ago [-]
Cloning a repo owns your computer. Is that something you expected?
xeyownt 11 hours ago [-]
That's not what's happening.
Using AI tool over that repo does, but you have to launch it before the AV kicks in.
iainmerrick 8 hours ago [-]
Only if you think opening Cursor.app counts as “using an AI tool”. Most reasonable people wouldn’t expect an AI-enabled text editor to hack their machine right away -- it should have the common decency to wait until you type something into the AI agent panel, then hack you!
_AzMoo 22 hours ago [-]
This attack is exactly why IDE's have a concept of trusted and untrusted locations.
paxys 21 hours ago [-]
That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.
I think many people gets tired so much they will simply trust all the locations.
Shorel 15 hours ago [-]
It is a very obvious thing in UNIX world.
This should not happen, no matter if it's Cursor or VIM or whatever program you are using.
So, yes, it is a serious issue, and it's more of a Windows fuckup than Cursor itself. It's basic OS behaviour that's been fixed in UNIX for decades.
You want to run a program in the current folder, you write ./program, everyone know this.
melodyogonna 12 hours ago [-]
People are offloading a lot of responsibilities to tools. If you pull a repository from Github without doing due diligence then you can't blame Cursor for getting compromised
iainmerrick 8 hours ago [-]
What’s due diligence? Reading all the code on GitHub?
That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...
hnfong 7 hours ago [-]
So I clone a repo from Github and try to do due diligence before compiling and executing the code. I open the project with my IDE/text editor, and boom, I get pwned while doing the due diligence.
Unless it's Cursor's stance that people should use Emacs or whatever to check the repo before opening it, this is "you're holding it wrong" level stupid gaslighting.
22 hours ago [-]
beart 23 hours ago [-]
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.
Xirdus 22 hours ago [-]
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.
beart 20 hours ago [-]
Okay... but when "you" is a junior engineer on your team and now you are suddenly spending your entire weekend dealing with malware, it's kinda on you as well.
krater23 22 hours ago [-]
Downloading this attachement doesn't executes it. Checking out a branch in this case executes the file in the branch. Thats a big difference.
22 hours ago [-]
dev_daftly 18 hours ago [-]
In this case, if you just run a git command yourself it executes the file as well.
brookst 16 hours ago [-]
On windows I guess?
On Linux and MacOS you'd need to run ./git to execute a malicious binary in the cloned repo.
libeclipse 21 hours ago [-]
Bro thinks cloning a repo means you're already compromised
spullara 20 hours ago [-]
I agree, this isn't a vulnerability at all. Now that it's public, I'm not even sure I would do anything about it if I were them.
jeremyjh 20 hours ago [-]
You think opening a git repo I just cloned should execute code in that repo?
x3n0ph3n3 18 hours ago [-]
Maybe powershell shouldn't include the current directory in the PATH.
Illniyar 24 hours ago [-]
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.
shitter 23 hours ago [-]
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.
Illniyar 16 hours ago [-]
Ostensibly you've ran git before and never saw something like that, seeing a security warning on running git should raise some eyebrows.
jofzar 18 hours ago [-]
I'm not a windows developer or a ide developer, but I would check the hash against known good git.exe and then only run if it matches it.
x3n0ph3n3 23 hours ago [-]
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?
loumf 23 hours ago [-]
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).
x3n0ph3n3 17 hours ago [-]
Yet PowerShell does it by default.
julianz 17 hours ago [-]
I don't think it does?
> cd C:\Temp
> copy "C:\Program Files\Git\bin\git.exe" .\fred.exe
> fred
fred: The term 'fred' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
jwolfe 23 hours ago [-]
If bash placed the current directory in your PATH by default, then yes.
lyu07282 21 hours ago [-]
Could file a CVE with Microsoft then, cause thats kinda what cmd.exe is doing:
> git clone git://evil evil
> cd evil\
> git status
The last line would execute git.exe from the cloned repo, wouldn't it?
frabera 11 hours ago [-]
No, `git` uses the binary in path, to use the repo file it should be `./git.exe`
kubanczyk 10 hours ago [-]
On Linux.
Look for `NoDefaultCurrentDirectoryInExePath` if you want to learn about Windows.
6 hours ago [-]
shitter 23 hours ago [-]
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.
Firehawke 21 hours ago [-]
Not with bash. If your distro is putting ./ into the path then that's absolutely a high severity CVE with your distro's config.
minraws 1 days ago [-]
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...
evolve-maz 22 hours ago [-]
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.
SpicyLemonZest 24 hours ago [-]
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).
firer 23 hours ago [-]
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.
orphereus 23 hours ago [-]
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?
undecisive 7 hours ago [-]
We're in the worst of all worlds. Sometimes it feels like you only know it's a human because the AI would have over-explained.
But yeah, this security company only prodded, what, once or twice a month for 7 months? I mean, if they really truly cared, they would have found the CISO's home address, broken into their house, painted the reproduction steps on the inside of their front door (to avoid accidental disclosure), created a few "beginner friendly" repos with a git.exe that DDoS's their auth servers, got a job as a night cleaner in their offices, waited for one of the developers to leave their machine unlocked then fixed the vuln themselves.
It's just another capitalistic money grab, them posting their security concerns. Ugh.
firer 22 hours ago [-]
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.
bragr 23 hours ago [-]
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.
ncruces 19 hours ago [-]
Stuff that cares about security fixes this, though:
The functions Command and LookPath look for a program in the directories listed in the current path, following the conventions of the host operating system. Operating systems have for decades included the current directory in this search, sometimes implicitly and sometimes configured explicitly that way by default. Modern practice is that including the current directory is usually unexpected and often leads to security problems.
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
Chu4eeno 22 hours ago [-]
Yes, but it's an old known security gotcha people developing for Wintendo have to guard against.
whateveracct 22 hours ago [-]
that sounds like Cursor has a bug and vuln on Windows to me
dools 17 hours ago [-]
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
ajhenrydev 1 days ago [-]
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
gene91 1 days ago [-]
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.
paxys 21 hours ago [-]
This is exactly why every AI agent should run in a sandbox.
TZubiri 16 hours ago [-]
Don't think that would trigger the bug, it needs to be at the repo root when the user opens the agent CLI, it's not like the agent is calling another agent CLI process with the new repo root as its project root.
AntonyGarand 1 days ago [-]
The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised
4ndrewl 22 hours ago [-]
It's curious the number of people here who can't link these two things.
dev_daftly 18 hours ago [-]
git clone a repo, cd into the directory, git checkout ..., and you're compromised
dalemhurley 23 hours ago [-]
If your an opensource developer you may get a pull request containing the the git.exe
ryanisnan 22 hours ago [-]
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.
pixl97 1 days ago [-]
>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 1 days ago [-]
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.
24 hours ago [-]
ribs 23 hours ago [-]
I think you’ve got it wrong; no malicious payload need be on your box already. That’s not what the article says.
JMKH42 1 days ago [-]
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 24 hours ago [-]
From my reading, boom happens at "open up cursor".
dev_daftly 21 hours ago [-]
You can leave out cursor and it would do the same thing.
Illniyar 24 hours ago [-]
you would only need to open it to be exploited, not edit or prompt. Allegedly
dalemhurley 23 hours ago [-]
From the article it occurs when Cursor is loaded. iDEs do a lot of stuff when they first open.
dclowd9901 23 hours ago [-]
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?
hack1312 5 hours ago [-]
Cursor, being based on VSCode, does have the Workspace Trust feature.
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.
alansaber 23 hours ago [-]
Startups historically are not the most security oriented
dhosek 18 hours ago [-]
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?
hmokiguess 21 hours ago [-]
The 0 day vulnerability is actually a developer is using Windows
aliasxneo 1 days ago [-]
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.
gruez 1 days ago [-]
>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 1 days ago [-]
Windows doesn’t really have a default login shell like Unix.
Windows Terminal defaults to PowerShell which does not suffer from this issue.
inigyou 21 hours ago [-]
Windows has a default login shell which is explorer.exe.
Windows also has a system(const char*) which certainly does something.
conartist6 1 days ago [-]
and ever since, this approach has been a critical pathway for some billion dollar business probably. hooray
pixl97 1 days ago [-]
I see you also work in enterprise software.
varenc 17 hours ago [-]
I doubt it. This is just normal Windows behavior. If you call out to a shell and have it run a
`git` command the system has to decide where the git binary is. A quirk of Windows is that first it searches the current directory for a `git` executable, and then it searches directories defined in PATH. If there's an executable git.exe in the current dir, that gets ran. I assume Cursor's behavior is the same across platforms but this is only a Windows vuln
because Windows picks binaries in the current directory before PATH.
A Windows
user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.
imglorp 21 hours ago [-]
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.
nickelpro 21 hours ago [-]
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.
nosefrog 1 days ago [-]
Would be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").
varenc 17 hours ago [-]
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.
psd1 10 hours ago [-]
Not in powershell, no, because . is not in PATH (unless you put it there).
If you tab-complete `git` it will resolve to `.\git.exe` but it you merely hit enter then it will search PATH and not the CD.
dhpe 17 hours ago [-]
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.
iainmerrick 8 hours ago [-]
If it happens out of the box with fresh installations of both Windows and Cursor, I’d say it’s a serious vulnerability in at least one of those.
Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.
cute_boi 17 hours ago [-]
> While some responsibility should be on the user
User should always be responsible before downloading pdf, excel and its macros. There are so many way things can get infected..
brookst 16 hours ago [-]
When you clone a git repo, do you check whether there are PDFs in it?
TZubiri 16 hours ago [-]
Critical difference is that PDF is a data file, while a git.exe is an executable marked to the OS as executable.
aniceperson 23 hours ago [-]
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.
noisy_boy 13 hours ago [-]
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?
physix 19 hours ago [-]
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.
psd1 6 hours ago [-]
The reason you need AV on windows is because you are a granny who gets an "FBI" warning on a dodgy webpage and clicks the "pwn my shiz" button.
If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.
I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.
I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.
3plefly 16 hours ago [-]
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
SV_BubbleTime 16 hours ago [-]
I mean… is our idea of repeatability really ready for subjective actions from LLMs?
We spent like ALL the years making sure computer would always give repeatable objective deterministic answers… then one day we’re nah fuck that I want a slot machine!!
With tightly coupled agents, how could you ever really prove that it is or isn’t a problem?
Try and fuzz I guess? But in a many billion parameter model that seems like you could never really be sure either.
One day the LLM could just decide, “oh, I’ll run this git.exe!”
16 hours ago [-]
brookst 16 hours ago [-]
The vuln is supposedly in the cursor IDE, not an LLM-mediated iteraction
paxys 21 hours ago [-]
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?
AussieWog93 20 hours ago [-]
The difference is that I expect "npm install" to execute code, where I do not expect merely opening a repo to look at the files in Cursor to execute anything.
paxys 20 hours ago [-]
IDEs do syntax highlighting, typechecking, linting, automatic git refreshes. All of this happens in the background without you executing any code. If you open a Typescript project in VS Code and it automatically shows you a list of errors where do you think it got them from? It ran the tsc executable in your node_modules folder.
tom_ 10 hours ago [-]
Visual Studio Code asks you if you trust the files in the folder you open, or at least it always has done for me. Presumably this stuff stops working if you don't?
In most languages, none of those things involve execution of code in the repo. In languages that do - for example Elixir - it prompts you to trust them first.
AussieWog93 14 hours ago [-]
I'm a Python dev so don't do much typescript, this sounds crazy too!
jeremyjh 20 hours ago [-]
Cursor is an editor. Why is it executing untrusted code when a folder is opened? Opening a folder is not equivalent to executing a script contained in the repo. How can you think that is ok?
dev_daftly 18 hours ago [-]
It's not executing untrusted code, it's calling git when you have a malicious version of git on your system
jeremyjh 17 hours ago [-]
No, read the report. It will call an executable called git.exe in the untrusted repo.
20 hours ago [-]
Shorel 15 hours ago [-]
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.
chrisjj 24 hours ago [-]
> 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.
awongh 23 hours ago [-]
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?
beart 23 hours ago [-]
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.).
awongh 23 hours ago [-]
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.
beart 23 hours ago [-]
Oh yeah that's a good point - two layers of auto executing scripts/binaries.
redwood 19 hours ago [-]
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?
theaniketmaurya 10 hours ago [-]
First grok cli and now this
21 hours ago [-]
throwitaway222 15 hours ago [-]
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..
UnwrapComment 12 hours ago [-]
In this case, simply cloning a repository containing such an executable is enough. This isn’t a common bug or a gotcha.
ralferoo 10 hours ago [-]
Although on Windows, the current directory is checked before PATH, unlike UNIX-based systems that require the current directory to be explicitly included in the PATH if that's the behaviour you want.
So for any repository with git.exe in the root, if you then ran another git command from a DOS prompt with the repo as your current directory then it would give the same bad outcome of running the git.exe from the repo.
I'm not saying that it's good that it's happening, but it doesn't seem like it's their bug to solve per se, it's just a feature of using Windows. Of course, they probably could work round it by parsing the PATH themselves and locating a git.exe that isn't in the current directory.
vanyaland 23 hours ago [-]
Does the git lookup run before the trust check, or ignore it?
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.
beart 23 hours ago [-]
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.
827a 17 hours ago [-]
They should definitely fix it, but that's mostly because its an "unnecessary autoplay" so to speak. There's plenty of "necessary autoplays" out there, and AI is going to add more and more every day, because that's where productivity comes from. But, why Cursor would ever need to execute the git binary in your project directory is beyond me; very clearly a bug.
Their ignorance of the bug report is also very clear and concerning negligence.
But I think simultaneously, the security team is making a mountain out of a molehill. This is a classic thing security teams love doing; everything is military defcon P0. So, its important to check them regularly, and remind them that the most secure system is no system; they are but one part of a greater ecosystem.
charcircuit 12 hours ago [-]
Suspiciously the authors do not say if this works in restricted mode. This is not considered a vulnerability outside of restricted mode.
nubg 1 days ago [-]
> 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 24 hours ago [-]
Maybe the bug report got ignored because they posted another 1000 slop reports, who knows.
dakolli 24 hours ago [-]
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.
mike_hock 10 hours ago [-]
Yes, the question is whether it drowned in a myriad of other LLM "assisted" reports, because that would be a way in which a simple straightforward report could be missed.
skeledrew 24 hours ago [-]
Wonder who's fault it is when a critical security issue goes unresolved because "slop" report (sure ain't the reporters').
chrisjj 24 hours ago [-]
> 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...
dalemhurley 23 hours ago [-]
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
iririririr 18 hours ago [-]
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
TZubiri 16 hours ago [-]
>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.
dublecc 7 hours ago [-]
[flagged]
glasffordd 9 hours ago [-]
[dead]
jyswee 10 hours ago [-]
[dead]
DaWe01 1 days ago [-]
[flagged]
fatmacelik6894 9 hours ago [-]
[flagged]
sieabahlpark 1 days ago [-]
[dead]
yieldcrv 19 hours ago [-]
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
> 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.
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.
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 the capacity.
The ones we're seeing show clear evidence of being AI-generated, are often incorrect or duplicated, but they also show clear evidence of the AI having done its homework and spent a while crawling our API.
Even if we were getting reports at the lower bound you're describing, those would be even easier to triage: just add a quick step to check if the API in question even exists, then if it does that very cheap "where is this API" query becomes part of the input to the second-level triage that spends more tokens.
Not defending HackerOne, but pointing out that it's not a black-and-white issue.
It's hard to vibe code security.
The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
Conversely, running human or LLM-generated code through multiple LLMs to look for security holes is a fantastic way to increase security.
Too busy being acquired by SpaceX?
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?
https://www.reddit.com/r/programming/comments/zes1co/visual_... (2022)
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
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.
Edit: yes I get that there's a trust system, but I know a lot of people just trust everything in a directory.
https://cursor.com/docs/agent/security#workspace-trust
You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around since day one.
To me the App is preparing to do some work so it is more responsive to my requests. This is a classic trade off between security and performance, where the odds of a malicious virus being in the root of your project are very small if you are already taking best practices.
Perhaps what we really need is Microsoft to change the execution order and that the maintainers of Git add a new feature where we can block executables being in the root of a repo (or in the whole of a repo). That would prevent every app having to make the same workaround, fix the issue upstream and you'll never have to think about it again.
Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution
What do you think PATH variables are for? Cursor just immediately adds the repo to your PATH, iiuc, without user approval.
There is not easy solution, the landscape has changed and if care about security, you just need to allocate more human resources. Another layer of LLM checks won't help.
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.
Of course, that ship has long sailed, for all major IDEs. Heck, VSCode SSH and devcontainer remotes allow RCE by design.
Check (and double check and triple check) your sources. If a malicious executable made it to your computer it is already too late.
Not to mention that Cursor has an agent permissions model that this presumably sidesteps!
We should never ever download any pdf or excel macros etc.. from untrusted source.
You do not expect an agent-level app to run untrusted binaries. You expect prompt injection, etc.
And I don't at all agree that a malicious executable landing in some directory is already game over. Plenty of zip files have malicious executables, it doesn't mean you say "oh, my zip extractor should just run every executable because if one's bad I'm already toast".
So yeah, this is a major issue
Containers are really good now, there's zero reason why every extension and LSP isn't containerized.
Also agents inside a container. It's very nice because I have zero trust for harness permission systems. But again, why aren't the tools designed from the ground up to be containerized?
how is that different from the good old days of
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.
"Make things as simple as possible, but no simpler." - commonly known quote.
We're making things so simple, the users don't get to have a proper chance at learning what's happening. Training people away from giving programs access, makes it opaque and dangerous. Unfortunately at the same time for non technology inclined users even Windows approach of file->Properties->Security visual UI proves challenging.
Diabolical idea. Anyone know if there's been anything in the wild that did this?
In any case, the curl|bash from a website is way worse as it leaves no trace. Here, you have an artifact, and multiple steps, so the probability that an issue can be detected is higher and when someone gets compromises one has a change to figure out what happened and warn others. (so good practice to copy the file somewhere else). People look at this only from purely "can I get compromised" perspective, but overlook this community aspect.
Also the archive probably won’t go and fetch a bunch of other scripts and run them (probably…) while doing so is usually the script’s primary purpose. So you’re not just trusting the people who published the script, at the time they published it. You’re trusting them and everyone they trust to still be good actors now.
That’s different to it being the standard way to install self-published bundles of scripts from all over the internet.
It is the same as autorun.exe on some CD - I put some CD in my CD-ROM and my Windows are compromised.
You can argue that I should not clone unknown repos, I should inspect each and any file in the repo, look for git.exe or any other suspicious binary and etc. I should not put untrusted CDs or USB sticks into my computer.
However the reality of it is that it will not be the user who inspects USB stick in some contained environment, it will be security policy which disables autorun. Same as Cursor should disable this.
Using AI tool over that repo does, but you have to launch it before the AV kicks in.
https://code.visualstudio.com/updates/v1_57
That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...
Unless it's Cursor's stance that people should use Emacs or whatever to check the repo before opening it, this is "you're holding it wrong" level stupid gaslighting.
On Linux and MacOS you'd need to run ./git to execute a malicious binary in the cloned repo.
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.
I haven't used Windows in a while so pardon if I'm missing something.
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?
Look for `NoDefaultCurrentDirectoryInExePath` if you want to learn about Windows.
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.
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.
How do they not truly care about helping? Also what sunk cost? What does that mean?
But yeah, this security company only prodded, what, once or twice a month for 7 months? I mean, if they really truly cared, they would have found the CISO's home address, broken into their house, painted the reproduction steps on the inside of their front door (to avoid accidental disclosure), created a few "beginner friendly" repos with a git.exe that DDoS's their auth servers, got a job as a night cleaner in their offices, waited for one of the developers to leave their machine unlocked then fixed the vuln themselves.
It's just another capitalistic money grab, them posting their security concerns. Ugh.
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.
https://go.dev/blog/path-security
The functions Command and LookPath look for a program in the directories listed in the current path, following the conventions of the host operating system. Operating systems have for decades included the current directory in this search, sometimes implicitly and sometimes configured explicitly that way by default. Modern practice is that including the current directory is usually unexpected and often leads to security problems.
https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
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
I'm also so tired of people groaning about AI writing, yes, it's annoying, but attack the message, not the messenger.
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.
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.
They ship it disabled.
https://cursor.com/docs/agent/security#workspace-trust
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 Terminal defaults to PowerShell which does not suffer from this issue.
Windows also has a system(const char*) which certainly does something.
A Windows user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.
Agents should be no different.
This is why the upstream didn't take it seriously, this has been known for literal decades.
That said, Cursor should at least have some "trust this directory?" dialogue.
If you tab-complete `git` it will resolve to `.\git.exe` but it you merely hit enter then it will search PATH and not the CD.
Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.
User should always be responsible before downloading pdf, excel and its macros. There are so many way things can get infected..
Not an active Windows user, but I can't imagine any sane person working on Windows OS without malware protection.
If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.
I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.
I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.
We spent like ALL the years making sure computer would always give repeatable objective deterministic answers… then one day we’re nah fuck that I want a slot machine!!
With tightly coupled agents, how could you ever really prove that it is or isn’t a problem?
Try and fuzz I guess? But in a many billion parameter model that seems like you could never really be sure either.
One day the LLM could just decide, “oh, I’ll run this git.exe!”
In most languages, none of those things involve execution of code in the repo. In languages that do - for example Elixir - it prompts you to trust them first.
Obvious answer is obvious. The devs do not consider it a bug.
Or, the infected package could also copy that file into the parent project's root.
So for any repository with git.exe in the root, if you then ran another git command from a DOS prompt with the repo as your current directory then it would give the same bad outcome of running the git.exe from the repo.
I'm not saying that it's good that it's happening, but it doesn't seem like it's their bug to solve per se, it's just a feature of using Windows. Of course, they probably could work round it by parsing the PATH themselves and locating a git.exe that isn't in the current directory.
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.
This exploit feels very similar to me. I don't know if there's a specific name for this classification of AutoPlay issues.
Their ignorance of the bug report is also very clear and concerning negligence.
But I think simultaneously, the security team is making a mountain out of a molehill. This is a classic thing security teams love doing; everything is military defcon P0. So, its important to check them regularly, and remind them that the most secure system is no system; they are but one part of a greater ecosystem.
> 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.
Got to wonder why trusted repositories are excluded...
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
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
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.
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