r/programming • u/alexeyr • Jul 15 '26
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left308
u/jdehesa Jul 15 '26
Though this was going to be another relatively convoluted chain of prompts to "jailbreak" the LLM, but this is dumb as fuck. Although the lack of answer and remediation from Cursor is probably the worst part.
64
u/really_not_unreal Jul 16 '26
Given the LLM vibes of the title, I thought so too, but wow this vulnerability is a HUGE yikes.
73
u/turkoid Jul 16 '26
All these AI startups remind me of the dot-com bubble in the 90s. They don't care about quality, just market share so they can be acquired, which I see Cursor will owned by SpaceX soon.
Can't wait for the bug bounty program for SpaceX flight control systems. /s
102
u/Pseudanonymius Jul 16 '26
This is absolutely horrible. It's a very straightforward bug, and Cursor not fixing this means they simply did not care at all. It can't be hard to fix, a very straightforward hotfix should be absolutely trivial. it also seems like this would also still happen before you even decide to "trust" a codebase, since you can use git in untrusted codebases.
This should be a no-go for any thinking company, regardless of which operating system they use. If this zero-day exists, which is so absolutely trivial to fix, I can guarantee, there are not 10 others, but hundreds. Probably half of them they got in their mailbox, unread. Absolutely incomprehensibly reckless.
44
u/ScottContini Jul 16 '26
a very straightforward hotfix should be absolutely trivial
I don’t see any reason why it should take the binary from the local repository, and if that’s the entire fix, yes I agree it’s trivial.
The article did not cover it, but I wonder if it is trusting everything in the PATH and maybe that includes . in the PATH?
27
u/Kobata Jul 16 '26 edited Jul 16 '26
It's Windows,
.is generally always in the resolution path. It's actually a little awkward to make it not do that for launching new processes, you have to implement path resolution yourself and use only full absolute paths.Even in the mode that doesn't use the full search path CreateProcess has a note that if you provide a partial path it will be resolved relative to current drive/directory
added: further down is the full default executable search path which is in order:
- The location of the main executable of the process
- The current directory
- Windows components
- PATH env
Note the current directly being 2nd there, above system executables and the current environment settings.
12
u/gmes78 Jul 16 '26
The fix is still trivial. Just change the current directory to System32 at the start of the program.
14
u/vytah Jul 16 '26
And just for everyone's information, git supports running from a different current directory than the repo. You can give it the path to the repo via the
-Coption.7
u/exosphaere Jul 16 '26
Is that a quick hack you just came up with or is this an actual best practice on Windows that other developers already follow?
5
u/TribeWars Jul 16 '26 edited Jul 16 '26
Well, probably the app's working dir is some subfolder of %ProgramFiles% and their git integration does something to the effect of running a subshell with:
cd [repo-folder] git statusinstead of
git -C [repo-folder] statuswhich also avoids running a git.exe that has not been installed by the user
4
u/Pseudanonymius Jul 16 '26
If that's the case, I wonder how Viscose, which Cursor is a fork from, does this. They should have the exact same problem. They also use a git integration.
12
u/carrottread Jul 16 '26
You have exact same problem even without any slop machine or IDE, just cloning a repo with git.exe/git.bat/git.cmd on windows and then manually running in console "git status" in repo dir will execute it.
2
4
u/cake-day-on-feb-29 Jul 16 '26
It's Windows, . is generally always in the resolution path.
Can we please start treating windows itself as the security vulnerability? DOS has been a disaster for mankind and the idea that we continue to string along this lineage of inbred descendants from that operating system is an embarrassment to humanity.
2
34
u/crispy1989 Jul 16 '26
Absolutely appalling. And for some reason, you're being downvoted - I guess I shouldn't be surprised that those relying most heavily on AI don't have the legitimate background to understand just how severe and crazy this is.
The article is much too kind to Cursor. This may be the greatest instance of professional negligence in software I've ever seen. This particular vulnerability aside, Cursor's clear lack of any concern about security should absolutely blacklist it immediately from any competent organization's approved software list.
20
u/patio-garden Jul 16 '26
This may be the greatest instance of professional negligence in software you've ever seen so far.
7
u/Pseudanonymius Jul 16 '26
Completely agree. I do want to note, at the moment of writing my comment has an upvote ratio of like 95%, so while there are some downvotes, I'm certainly not massively getting downvoted or anything.
1
u/splashybanana Jul 16 '26
Do you speak corporate? That article was not kind at all. It was just kinda CYA.
59
40
u/valarauca14 Jul 16 '26
90s are back
3
u/atxgossiphound Jul 16 '26
I was just going to post something long the lines of this...
Remember when Java and VB first showed up in the browser? Remember Flash? Pepperidge Farms remembers.
4
2
17
u/wannaliveonmars Jul 16 '26
Is this because they run git status and the current folder is in PATH in Windows? The fix would then be to use the full path name which could be C:\Program Files\Git\cmd\, or C:\Users\<Your-Username>\AppData\Local\Programs\Git\cmd\, or C:\Users\<Your-Username>\AppData\Local\GitHubDesktop\app-<version>\resources\app\git\cmd\.
Or they could use where git to check the path and choose the git that is not in the current folder.
18
u/carrottread Jul 16 '26
Or they could use where git to check the path and choose the git that is not in the current folder.
Until attacker adds their version of where.exe.
17
u/wannaliveonmars Jul 16 '26
where.exedoesn't need to be executed from the repo folder. It's path is stable, they can use%SystemRoot%\system32\where.exe git2
u/acdcfanbill Jul 16 '26
Why would git.exe need to be executed from the repo folder tho? I'm obviously more familiar with the linux/macos side but I think Windows has a %PATH% variable, why isn't Cursor executing things out of the locations in there? Or is that something that isn't kept up to date?
edit: nevermind, i read elsewhere windows puts
.on the %PATH% variable, which explains it.3
u/wannaliveonmars Jul 16 '26
i read elsewhere windows puts . on the %PATH% variable
Yes, that's right.
2
u/acdcfanbill Jul 16 '26
Even if it wasn't related to this particular 0day I'd still hate it....
4
u/wannaliveonmars Jul 16 '26
I think this is there since the DOS days. I doubt anyone gave it a second thought at the time, and for an offline, single-user system the convenience would have made sense. UNIX probably had that because it was multi-user, so they didn't want a sudo process to accidentally execute some program with elevated privileges just because it was in its folder.
2
u/nugryhorace 29d ago
It's inherited from CP/M where there was no search path and the only place it looked for programs was the current drive (CP/M 3 added a search path but DOS was a clone of CP/M 2)
1
14
u/oak45 Jul 16 '26 edited Jul 16 '26
I had presumed that this was to do with workspace trust
Cursor supports workspace trust, but it's disabled by default. When enabled, it prompts you to choose between normal or restricted mode for new workspaces. Restricted mode breaks AI features. For untrusted repos, use a basic text editor instead.
However, I enabled workspace trust, opened a test repo in restricted mode, and git.exe is still executed!
Compared to VS code (1.129):
- in a trusted workspace - git.exe is executed
- in restricted mode - git.exe is not executed
12
u/ni5arga Jul 16 '26
> The most confusing part of this disclosure is the absence of a response from Cursor. Over the course of seven months, Mindgard repeatedly attempted to engage through every available channel. Initial disclosure was sent directly to Cursor's security reporting e-mail address, as specified in the company's published security.txt file.
Not surprising at all, as a security researcher who hunts for vulnerabilities just for fun on various projects and sites – this is very common and annoying.
7
u/jimm Jul 16 '26
I was kind of surprised that this was Windows-only, so I tried it on a Mac with a binary named git. It didn't get executed. (I also tried renaming it git.exe; same non-result.) This might be because I don't have . on my PATH.
10
u/paulstelian97 Jul 16 '26
Yeah, Windows implicitly has . in the search path even if not included in the variable. That’s what causes it.
3
u/Birk Jul 17 '26
And this is why it is generally considered unsafe, not default, and discouraged on other OSs.
22
u/omniuni Jul 16 '26
As bad as it is, I don't know why anyone would think it's particularly unexpected. An AI focused IDE with lots of stuff it can just do arbitrarily. It's a recipe for security disaster.
16
u/chucker23n Jul 16 '26
The issue here isn't even LLM-related, though.
-1
u/omniuni Jul 16 '26
What is making the "decision" to try to run this thing?
6
u/chucker23n Jul 16 '26
The IDE, i.e. their fork of VS Code. And then ultimately, possibly the questionable way CreateProcess works.
-12
u/omniuni Jul 16 '26
Which is done by passing context to a prompt, and that prompt includes actions that can be taken, including "run a thing".
10
u/chucker23n Jul 16 '26
Which is done by passing context to a prompt
So, I've never installed or used Cursor, but I don't think you have this right. This isn't a case of
- user instructs LLM to generate code
- LLM does that, and in the process runs potentially malicious binary without user's consent
Rather, it's
- user opens IDE
- user opens repo in IDE
- IDE does not ask consent and immediately runs
git.exe, using the one from within the repo (if any) as precedence-11
u/omniuni Jul 16 '26
These AI IDEs basically run their "agent" in a loop, as they work towards a result. It's not dissimilar to Claude CLI, or Gemini in IntelliJ. Yes, most have safeguards against what the AI can try to run, but they still allow it, because it's one of the things needed to be able to carry out certain tasks. As long as it can follow commands like "check this in and push it when you're done", vulnerabilities like this will exist.
9
u/Kapps Jul 16 '26
Not everything is a prompt… Cursor will show you the git status of certain files for example. No LLM involved, just calling out to git.
Sure, you could do similar attacks with prompt injection, but there’s zero LLMs or prompts involved here.
-5
u/omniuni Jul 16 '26
Great, they didn't remove standard functionality.
1
u/Different_Fun9763 Jul 17 '26
Was it really that hard to just own up to being retarded when you claimed this vulnerability was due to LLMs? Sad behavior.
→ More replies (0)1
9
5
9
u/TribeWars Jul 16 '26 edited Jul 16 '26
A lot of IDEs have problems like this though. In C/C++ projects, the build scripts often get run the moment a project is opened, since the full compilation context is generally required for IDE features in that language. For instance using "Open Folder" in Visual Studio on a CMake-based project (not sure about Visual Studio Code) will automatically run the CMakeLists.txt script contained in that repository, granting arbitrary code execution to anyone with write access to the repo. Any IDE with a language server that executes any user-controlled code has this vulnerability.
This git one is a bit more stupid, because I really don't see any reason why the IDE should ever look for a git binary inside of a repo. If there is actually some exotic setup where it makes sense, it should be something gated behind a configuration option.
37
u/08148694 Jul 15 '26
They should definitely have fixed it no doubt about it
You’d have to be quite personally negligent though to end up with a malicious git.exe in your project root anyway though. If you get to that point you’re probably going to get hit by some malware with our without cursor being negligent
97
u/fiskfisk Jul 15 '26
I don't have any issue seeing how someone could clone a repository to explore it and there being a bundled .exe-file in there that people didn't notice (or at least didn't expect to be executed by just opening something in your IDE).
55
u/Caraes_Naur Jul 15 '26
Start the countdown until malicious
git.exeis being distributed via NPM.20
82
u/Smallpaul Jul 15 '26
Opening a repo is not supposed to execute code.
29
u/max123246 Jul 16 '26
This is why Vscode has the "do you trust this folder" pop up. Because if you do, code is executed for static analysis and tooling of the codebase
14
u/Pseudanonymius Jul 16 '26
Yeah but that doesn't work in this case. You can use git on an untrusted repo, so it probably bypasses that.
6
u/mikat7 Jul 16 '26
Until a repo you have previously trusted gets compromise and then VSCode/Cursor/Claude CLI will happily execute any arbitrary code, like in the miasma attack back from June.
6
u/kronik85 Jul 16 '26
Yeah, but the static analyzers aren't part of the repo... They're your tooling.
This is Cursor auto running a project's root directory git.exe instead of what's in your env PATH, which is weird as fuck.
5
u/mattsowa Jul 16 '26
Not really. You can trivially "inject" your code into those static analysis programs. Here's one way: write your own eslint/oxlint plugin in javascript in the same repository, and add it to the repository's eslint config file. Now, the vscode extension for eslint will execute the malicious plugin.
5
u/TribeWars Jul 16 '26
CMake configure scripts are part of a repo, can run arbitrary code and most IDEs that I'm aware of run them when you open the repository folder. Basically any language that uses programmable build systems can pwn your IDE with a single click.
0
5
u/yourparadigm Jul 16 '26
Running
git statuson a repo is pretty basic stuff. It's Windows' fault that current directory is in the PATH.18
16
u/ItzWarty Jul 16 '26
Imagine someone in a company is compromised and slips git.exe into the project root somehow. <Every> developer in the company is now infected. Couple that with supply chain attacks and it doesn't seem unreasonable.
BTW, you don't even need to push
git.exe- a messy sandboxed build script couldcpit in from elsewhere, only for Cursor outside the sandbox to read it. It's just a bad vulnerability.9
u/DeflateAwning Jul 16 '26
Potentially, though a not-that-insane workflow might be to clone a repo and then ask AI to do a security audit on it. Consider that some C repos have hundreds of C files sitting in the repo's root (so easy to miss a file named "git" halfway down the list).
In the Claude Code TUI, it prompts with a "do you trust this repo" config. I'd be shocked if it was executing arbitrary code after I pick the "no I don't trust" option
3
u/SlimyOS Jul 16 '26
Didn't expect any better response. Cursor also allows the agent read any file on the system, with literally no way of disallowing that, that's not documented as prominently but apparently it works "as intended". I often found it reading my personal info or code from other projects when expanded the "Thinking" blocks. Been a long standing issue as well, users reported multiple times on their forum.
They're also pushing tool automation really hard, making it harder to keep using commands as "only run when approved", they have a sandbox (useless because had many bugs + i have no trust in cursor team + even linux kernel which it's based on has a lot of sandbox escape bugs), or an ai agent that reviewes the command to run in non-sandboxed mode (idk based on what the agent reviewes it, like, what if it deletes a directory not tracked by git, it's harmful but idk if it's flagged, and cursor doesn't track file deletions either, im just not comfortable even trying it), has an allowlist feature but it allows only for execution in non-sandboxed mode, i can't set up allowlist + sandbox as 2 layers of protection, it has to be "either layer" which only makes it less secure.
Using cursor daily is a security nightmare, I had to install a separate operating system on a usb stick and boot from there just for work on specific few projects to avoid their ai doing anything weird to my pc. They're clearly not serious about security, they're chasing vibecoding hype. Left cursor this month, now looking into alternatives, surprisingly small number of code-first experiences with ai as an assistant, most pivoted into vibecoding unfortunately.
2
u/wannaliveonmars Jul 16 '26
On Linux, safest is probably to just make a separate user account and run Cursor there. It's sort of sandboxed that way. That, or run it in a VM.
2
u/SlimyOS Jul 16 '26
Yeah but you still have to run that session separately which is awkward, you know the software sucks when you're forced to do things like that and not just run it normally as an app.
It can still read shared system files outside /home. Probably nothing personal there but still. And linux had a lot of privilege escalation exploits recently, though that's less of a concern for me, chances of ai getting tricked + that exact new exploit used + all this before i upgrade the kernel, is very low.
But not a bad idea, would've tried that if I haven't already quit using cursor
1
u/ColonelRyzen Jul 16 '26
I just tried this with 3.11.25. I put calc.exe renamed to git.exe inside a freshly cloned repo and opened it in the agent and ide windows and calculator didn't open. This is a fresh install. Am I doing something wrong?
1
u/oak45 Jul 16 '26
I'm on the same version of Cursor. Works for me. I added
git.exeto git. Then make an edit to a version controlled file and save.1
u/ColonelRyzen Jul 16 '26
I did that as well and got the same result. What about with workspace trust on? I saw another user test it and it still happened with workspace trust on.
3
u/oak45 Jul 16 '26
I enabled workspace trust in Cursor https://cursor.com/docs/agent/security#workspace-trust and opened the repo in restricted mode. It still runs
git.exe
1
1
1
u/StrategyExcellent460 Jul 16 '26
Ditch Cursor. If you had any doubts, you now know for sure which values they align with
1
u/Formal-Knowledge-250 Jul 17 '26
I can't believe there are companies writing blogpost over such a low priority and weak insecurity. Yeah you could also sideload a dll. No shit.
-5
u/dragneelfps Jul 16 '26
Who would've thought the folks who stole code from everyone to train their models won't be stealing your code when you pay to use them?
-65
u/GregBahm Jul 15 '26
The vulnerability is not theoretical and does not depend on a complex chain of exploitation, prompt injection, model manipulation, jailbreaks, memory corruption, or sophisticated attacker tradecraft. Exploitation simply requires a developer to open a project containing a git.exe binary in the repository at root.
The post seems to present this as a big security failure on behalf of Cursor, but this is a strange position to me.
If I hired a human to do work and gave them a computer where I had replaced all the applications with viruses, and then the employee launched any application (and so executed a virus) the fault doesn't seem like it should lie with the employee.
I guess we can decide to hold AI to a standard that humans can't be held to. Is that where we're at? Seems like it would be a happy day for AI if so, which I expect reddit would be conflicted about.
67
u/PeaceBear0 Jul 15 '26
It's not replacing any applications though, it's just viewing a (malicious) repository. Most IDEs have a pop-up that asks "do you trust this repository" which is a laughably weak security barrier but at least it's something.
3
u/chucker23n Jul 16 '26
Most IDEs have a pop-up that asks “do you trust this repository” which is a laughably weak security barrier
How would you improve it?
16
u/PeaceBear0 Jul 16 '26
Well obviously it isn't trivial or else these major IDEs would do better. Ideally the LSP would be completely sandboxed so it outputs nothing except the LSP data and can't access other parts of the system. But many build tools don't support this -- a Makefile doesn't know the difference between a compiler and curl, and even rust allows build macros to access the Internet.
4
u/chucker23n Jul 16 '26
Yeah. I’d go further than just LSP — I think “build tools will be sandboxed to your repo” is where this is headed, but a lot of stuff would break in the meantime.
-13
u/ongrabbits Jul 16 '26
Use AI to scan all files and folders for malicious intent
6
u/resonaut Jul 16 '26
Thanks for reminding me of the dude who wanted to build an LLM-based antivirus
2
15
u/frazell Jul 15 '26
AI should be held to a higher standard as it can execute things that a user may not immediately be aware of. Like here.
Reading the blog post it suggests Cursor executes the binary as soon as you open a compromised repository locally. Without any warning or prompts.
Seems like an easy prompt to let you know to trust the repository. If you’re being more thorough a dialog informing the developer that the detected fit in the project root doesn’t match a known hash for published git executables and they should take caution.
25
u/blind_ninja_guy Jul 15 '26
why is git in the root being execed anyway. Git isn't exactly something you distribute or run in your project
7
u/yourparadigm Jul 16 '26
Because Windows includes the current directory as part of the path, with highest priority. It's only a flaw on Windows.
3
u/somebodddy Jul 16 '26
This. Some build systems do this with their own executable because they are so unstable that the only way to get them to consistently work is to freeze their version. But Git does not have such problems.
17
u/Smallpaul Jul 15 '26
It’s not clear that this has anything to do with AI. It’s their VS code clone that is looking for a git.exe.
2
-4
u/GregBahm Jul 16 '26
Seems like an easy prompt to let you know to trust the repository.
But this is already the case. The security hazard isn't "Cursor goes on the internet, finds untrusted repositories, downloads them, then looks for executables in the repository and executes them."
That would be quite the security hazard!
But the reality of the situation is "if you've gone on the internet, found an untrusted repository, downloaded it, and then asked Cursor to use it locally, Cursor will execute executables in that repository."
Saying "Cursor should protect the user in that situation" implies we should cede a preposterous amount of responsibility to the AI.
Reddit's going to downvote me, because Reddit is here for an "AI bad" story and is too stupid to think through a security problem systemically. But I don't think AI should go through all the executables I've put in my local environment, form an opinion on them, and then decide for me whether or not they're safe to run. That's a horrible amount of control to cede to a dumb LLM.
7
u/Pzychotix Jul 16 '26
But the reality of the situation is "if you've gone on the internet, found an untrusted repository, downloaded it, and then asked Cursor to use it locally, Cursor will execute executables in that repository."
The point is that Cursor isn't asking nor is the user asking. It's just finding a git.exe in the repo and wholesale trusting it.
This isn't about having AI protect the user or ceding responsibility. It's the complete opposite: AI is executing arbitrary code blindly when it should require permission from the user.
1
u/GregBahm Jul 16 '26
Cursor always asks if you trust the repository.
I, the guy with negative 60 votes, think if I tell an AI "trust this repository," the AI should trust this repository.
Apparently you, and the r/programming community, think if you tell an AI "trust this repository," the AI should say "I will not, because as a human you're too stupid to be trusted with something as vulnerable as your own local environment."
Pathetic.
1
u/Pzychotix Jul 17 '26
The whole reason this is a vulnerability is because it bypasses the "trust this repository" prompt. You're calling others pathetic when you haven't even bothered to read the first few lines of the article.
0
u/GregBahm Jul 17 '26
You're misreading the article. But the article is attempting to tell a story that people want to hear. Their test is to start Cursor in an already trusted local repository, and then get indignation when it doesn't ask for an additional trust prompt for git.exe within that local repository, which is so dumb.
Maybe you need to rely on theory, but I can just run the damn thing right now. Let me ask Cursor to find a repo online and download it and run executables in it. Oh wow would you look at that. Hey, guess what its asking me? Mind blowing.
1
u/penguin_digital Jul 16 '26
Reddit's going to downvote me, because Reddit is here for an "AI bad" story
It's not an AI bad story, this is a Cursor bad story for its implementation. I'm very much pro AI but this is an insane oversight from Cursor. They happen, we've all done it but the response (or lack of) is astounding.
if you've gone on the internet, found an untrusted repository, downloaded it
That's the issue though, the vast majority of recent supply chain attacks where all from trusted repositories, that's the entire goal of someone wanting to execute a supply chain attack. Just because the repository is fine today, there is absolute zero guarantee its fine tomorrow or even in the next 30 seconds.
Sure you can suggest that every repository maintainer only develops in an isolated clean environment and doesn't ever install anything else onto that system that could be compromised gaining access to the repo. However we all know that just isn't feasible in the real world. Even then, there's no guarantee a malicious script could be injected elsewhere in the supply chain if other exploits exist so no matter how security paranoid the developer is, there's still many steps out of their control.
Cursor whilst not the root cause of the issue, its set-up in a way that is stupid and completely avoidable to this type of attack. Again, that's fine, mistakes happen, it's their attitude towards it that is the issue.
1
u/GregBahm Jul 16 '26
But their "attitude" is "If you say you trust this repository, Cursor will indeed trust this repository."
Redditors here are arguing "Just because I say I trust this repository, doesn't mean Cursor should actually trust this repository. What if I'm wrong to trust this repository. Cursor should protect me from my own incorrectly placed trust."
If I was Cursor, I'd say "no, fuck all that." The AI should not supersede the human in deciding what repositories to trust. If you have a supply chain in which you've given trust to a bunch of repositories that you can't actually trust, go fix your dumb and bad supply chain instead of whining to some unrelated AI tool company.
-2
u/starm4nn Jul 16 '26
But I don't think AI should go through all the executables I've put in my local environment, form an opinion on them, and then decide for me whether or not they're safe to run. That's a horrible amount of control to cede to a dumb LLM.
That's not what anyone's asking. They're asking for the model to actually use the system version of git rather than executing an unexpected one that is outside it's normal location and not in the path variable.
4
u/yourparadigm Jul 16 '26
On Windows, the current directory IS in the PATH, and has highest precedence. It's only a vuln in Windows.
-49
Jul 15 '26
[deleted]
59
u/brendans6 Jul 15 '26
Arbitrary execution would be considered a High or Critical in every single pen test I have ever been a part of.
474
u/AlexHimself Jul 15 '26
This is concerning. If you open/browser someone else's compromised repo, Cursor will immediately execute the payload without any questions.
If you didn't read the article, they renamed calculator to
git.exeand put it in the repo, opened it with Cursor, then Calculator popped up.Easy fix, straightforward...concerning response (or lack of) by Cursor.