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

171–180 of 222 posts

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

#171

Post by romanovcode »

hack1312 wrote: post #168
Aperocky wrote: post #141

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

We're back to autorun.exe times

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

#172

Post by username135 »

romanovcode wrote: post #171
hack1312 wrote: post #168

Earlier quoted context omitted.

Opening a freshly cloned repo in Cursor shouldn’t automatically execute a binary within that repo.

We're back to autorun.exe times

Time is a flat circle it seems

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

#173

Post by thayne »

koolba wrote: post #99
sofixa wrote: post #60

Earlier quoted context omitted.

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

Is it though? Cause you can have an agent analyze the reports to filter out the wheat from the chaff.

I suspect that is exactly what cursor did, and the agent (incorrectly) categorized this as chaff.

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

#174

Post by f311a »

Aperocky wrote: post #141

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

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

There is not easy solution, the landscape has changed and if care about security, you just need to allocate more human resources. Another layer of LLM checks won't help.

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

#175

Post by noisy_boy »

I am not certain about Windows but on Linux, aren't applications supposed to use PATH based resolution provided by shell for this? Why go to the root of the project directory at all looking for binaries? Because it has been become their favorite place due to readme / skills etc being there?

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

#176

Post by melodyogonna »

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…

People are offloading a lot of responsibilities to tools. If you pull a repository from Github without doing due diligence then you can't blame Cursor for getting compromised

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

#178

Post by UnwrapComment »

throwitaway222 wrote: post #162

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

In this case, simply cloning a repository containing such an executable is enough. This isn’t a common bug or a gotcha.

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

#179

Post by xeyownt »

brookst wrote: post #151
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.

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

Ok, so you download the repo, launch Cursor, it compiles code and run it (if not, why do you even use Cursor at the first place?). Same effect.

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

#180

Post by xeyownt »

paxys wrote: post #92
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.

How is it different from downloading and running the application itself from that website?

The illusion of security.
Post reply on HN