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

151–160 of 222 posts

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

#151

Post by brookst »

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.

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".

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

#152

Post by brookst »

dev_daftly wrote: post #125
krater23 wrote: post #77

Earlier quoted context omitted.

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.

On windows I guess?

On Linux and MacOS you'd need to run ./git to execute a malicious binary in the cloned repo.

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

#153

Post by TZubiri »

cute_boi wrote: post #135
dhpe wrote: post #133

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.

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

Critical difference is that PDF is a data file, while a git.exe is an executable marked to the OS as executable.

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

#154

Post by brookst »

SV_BubbleTime wrote: post #148
3plefly wrote: post #147

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

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…

The vuln is supposedly in the cursor IDE, not an LLM-mediated iteraction

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

#155

Post by brookst »

cute_boi wrote: post #135
dhpe wrote: post #133

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.

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

When you clone a git repo, do you check whether there are PDFs in it?

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

#156

Post by TZubiri »

gene91 wrote: post #15
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

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.

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.

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

#157

Post by infinite_spin »

demosthanos wrote: post #144
infinite_spin wrote: post #132

Earlier quoted context omitted.

Do you have a tier based system for identifying high value reporters? Like a credit score for vulnerability hunters?

Not formally, but we do informally recognize names and prioritize researchers who reliably turn up good results.

that might be a nice incentive for bounty hunters, a sign of recognition and a good metric for triage

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

#158

Post by Illniyar »

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.

Ostensibly you've ran git before and never saw something like that, seeing a security warning on running git should raise some eyebrows.

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

#159

Post by pseudohadamard »

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…

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.

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

#160

Post by uecker »

petalmind wrote: post #84
taneq wrote: post #76

Earlier quoted context omitted.

I’ve never got my head around how it’s apparently the done thing these days to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. I somewhat naively hope that this is because everyone is pushing single purpose VMs for that kind of install, but really I know better.

> to just copy a bash command from a website and run it (sometimes with sudo! O.o ) to install software. how is that different from the good old days of wget ftp://ftp.something.org/software-2.10.tar.gz tar zxfv ./configure make sudo make install ?

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.

Post reply on HN