[deleted]
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
91–100 of 222 posts
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#92Earlier 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.
How is it different from downloading and running the application itself from that website?
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#93Earlier 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 ?
Training people (esp. what passes for non-techies on Linux) to regularly copy-paste into the terminal is massively riskier than "click this URL". Just for starters, consider how easily you can make a web-page where you highlight X to copy it, but instead Y is delivered to your clipboard. Then on execute it could even redraw the terminal to pretend you pasted X all along.
Also, there's a convention or social-contract that everyone who downloads 2.10 ought to get precisely the same thing. This provides a foundation for other facets of security, like "it must have an expected hash" or "it must validate as signed by this public key". Also investigative actions like discovering when something suspicious got added, or detecting that the installer is trying to access the internet when it really shouldn't be.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#94Clone 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?
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#95I'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 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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#96This 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
wouldn't the attack vector be like this: I find a github repo, I want to contribute to it. I clone it, open up cursor, make an edit, commit, and boom, I am infected.
You can leave out cursor and it would do the same thing.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#97This is exactly why Unix PATH (and offspring) does not contain "." by default. If you unpack an untrusted archive and run "ls" you could get popped. Agents should be no different.
They aren't. This is a Windows quirk. Most IDE extensions which interface with git (or any other CLI program) from the CWD are "vulnerable" to the same attack.
This is why the upstream didn't take it seriously, this has been known for literal decades.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#98Clone 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?
The difference is that I expect "npm install" to execute code, where I do not expect merely opening a repo to look at the files in Cursor to execute anything.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#99> 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…
> 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.
Re: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
#100Earlier 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.
? 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!