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.
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
161–170 of 222 posts
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#162Uh, 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..
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#163Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#164> 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 t…
> 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.
> 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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#165I'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 vu…
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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#166The 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].
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#167I 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.
Stuff that cares about security fixes this, though: 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 i…
[deleted]
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#168As 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 art…
Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#169Does the git lookup run before the trust check, or ignore it?
Cursor ships with Workspace Trust disabled.
https://cursor.com/docs/agent/security#workspace-trust
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#170Earlier quoted context omitted.
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.
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.
I'm a Python dev so don't do much typescript, this sounds crazy too!