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

131–140 of 222 posts

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

#131

Post by demosthanos »

QuadmasterXLII wrote: post #108
demosthanos wrote: post #88

Earlier quoted context omitted.

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…

The token cost of a report is lower bounded by the number of tokens in the report * price per token of the cheapest model. The token cost of a good report is much higher, but sifting out the good reports is the entire problem.

In theory, yes, but are you actually seeing clearly-garbage lower-bound reports like this?

The ones we're seeing show clear evidence of being AI-generated, are often incorrect or duplicated, but they also show clear evidence of the AI having done its homework and spent a while crawling our API.

Even if we were getting reports at the lower bound you're describing, those would be even easier to triage: just add a quick step to check if the API in question even exists, then if it does that very cheap "where is this API" query becomes part of the input to the second-level triage that spends more tokens.

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

#132

Post by infinite_spin »

demosthanos wrote: post #88
app13 wrote: post #64

Earlier quoted context omitted.

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…

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

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

#133

Post by dhpe »

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.

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

#134

Post by jeremyjh »

dev_daftly wrote: post #128
jeremyjh wrote: post #110

Earlier quoted context omitted.

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

No, read the report. It will call an executable called git.exe in the untrusted repo.

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

#135

Post by cute_boi »

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

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

#136

Post by cute_boi »

shitter wrote: post #100
paxys wrote: post #95

Earlier quoted context omitted.

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.

? Doesn’t the code exec happen upon merely launching Cursor against a repository, without giving an agent any tasks? That’s clearly an issue at the Cursor application level, not some inevitable risk caused by the non-deterministic nature of LLMs. You can’t use the latter fact to excuse the former mistake Not to mention that Cursor has an agent permissions model that this presumably sidesteps!

I agree cursor can fix the issue, but the main issue is downloading anything from untrusted source. The repo may have AGENTS.md which can tell please install npm package from random repo and run pnpm start etc...

We should never ever download any pdf or excel macros etc.. from untrusted source.

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

#137

Post by oceansweep »

ivirshup wrote: post #115
oceansweep wrote: post #79

Earlier quoted context omitted.

It’s a thing in VSCode as well/has been a thing or things similar to it : https://www.threatlocker.com/blog/malicious-vs-code-tasks-js... (2026) https://www.reddit.com/r/programming/comments/zes1co/visual_... (2022)

I think those are both different in that they require the user to say they trust this code. Additionally the first is arguably not a bug (the code in tasks.json will indeed run if you say you trust the project) and the second was reported and fixed within two months.

Yes, my point was more so the underlying behavior of automatic execution of binaries associated with/inside of a git project exists already within vscode as a pattern, and so seeing cursor doing the same wouldn't be surprising.

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

#138

Post by cute_boi »

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

I think many people gets tired so much they will simply trust all the locations.

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

#139

Post by x3n0ph3n3 »

loumf wrote: post #56
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?

It’s been known for decades that you should never put your current directory in your PATH. There are endless opportunities for vulnerabilities then. I learned this in college in the 80’s (by not following it and getting owned).

Yet PowerShell does it by default.

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

#140

Post by varenc »

On Windows, if your shell was in a malicious repo's directory and you ran any "git" command, wouldn't the behavior be the same? Binaries in the current directory are considered before PATH. This seems like a broader issue.

That said, Cursor should at least have some "trust this directory?" dialogue.

Post reply on HN