Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cursor 0day: When Full Disclosure Becomes the Only Protection Left

mindgard.ai

Post reply on HN
Print view View original

121–130 of 222 posts

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#121

Post by thewhitetulip »

paxys wrote: post #95
shitter wrote: post #42

Earlier quoted context omitted.

The user's code folder? You mean the code I frequently pull from untrusted sources, unlike my .bashrc? Opening a GitHub project for review should not mean arbitrary code execution. Of course, that ship has long sailed, for all major IDEs. Heck, VSCode SSH and devcontainer remotes allow RCE by design.

The entire point of Cursor is to run autonomous coding agents. You are giving it a random untrusted repo, saying "hey it might have a virus, go crazy" and then getting mad that it caused harm? Check (and double check and triple check) your sources. If a malicious executable made it to your computer it is already too late.

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

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#122

Post by dhosek »

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?

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#123

Post by mort96 »

jjcm wrote: post #40

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 vu…

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.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#124

Post by jofzar »

shitter wrote: post #39
Illniyar wrote: post #21

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, uns…

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.

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.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#125

Post by dev_daftly »

krater23 wrote: post #77
Xirdus wrote: post #73

Earlier quoted context omitted.

I'd say checking out a malicious branch is in the same category as downloading a malicious attachment. By which I mean, it's kinda on you.

Downloading this attachement doesn't executes it. Checking out a branch in this case executes the file in the branch. Thats a big difference.

In this case, if you just run a git command yourself it executes the file as well.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#126

Post by dev_daftly »

AntonyGarand wrote: post #9
ajhenrydev wrote: post #8

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

The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised

git clone a repo, cd into the directory, git checkout ..., and you're compromised

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#127

Post by sandeepkd »

app13 wrote: post #64
wxw wrote: post #51

> 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…

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 l…

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.

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#128

Post by dev_daftly »

jeremyjh wrote: post #110
paxys wrote: post #94

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?

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?

It's not executing untrusted code, it's calling git when you have a malicious version of git on your system

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#129

Post by iririririr »

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

Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left

#130

Post by x3n0ph3n3 »

jeremyjh wrote: post #109
spullara wrote: post #103

Earlier quoted context omitted.

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.

You think opening a git repo I just cloned should execute code in that repo?

Maybe powershell shouldn't include the current directory in the PATH.
Post reply on HN