Live data from Hacker News

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

mindgard.ai

201–210 of 222 posts

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

#201

Earlier quoted context omitted.

We're back to autorun.exe times

but it is just a agents.md file lol

This has nothing to do with any language model or agent, this is just traditional deterministic code in the Cursor program.

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

#202
post #173
post #99

Earlier quoted context omitted.

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.

Ideally, they’ll be able to look back through the logs and find the original analysis from when the bug was submitted, figure out why it was incorrectly filtered, and use that to improve their automation.

The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.

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

#203

Earlier quoted context omitted.

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

If you can’t download anything safely, the web can’t exist.

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

#204
post #82

Earlier quoted context omitted.

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

That's not what's happening. Using AI tool over that repo does, but you have to launch it before the AV kicks in.

Only if you think opening Cursor.app counts as “using an AI tool”. Most reasonable people wouldn’t expect an AI-enabled text editor to hack their machine right away -- it should have the common decency to wait until you type something into the AI agent panel, then hack you!

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

#205
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

What’s due diligence? Reading all the code on GitHub?

That’s not a great interface, you probably want to clone it and open in your IDE so you can inspect the code properly...

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

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

If it happens out of the box with fresh installations of both Windows and Cursor, I’d say it’s a serious vulnerability in at least one of those.

Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.

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

#207
post #64
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…

Their CISO literally acknowledged it and then they all continued ignoring it again. This isn't just bad process, this is a broken security organization.

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

#208

Earlier quoted context omitted.

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

It isn't "a binary", it's git.exe (which has a very specific purpose). We are talking about an AI tool which wants to know the current state of the folder it is indexing, that's a reasonable thing for an AI to want to do. You then take the default of Windows execution order of: look for the executable in the current folder otherwise check the PATHs in order. This is a Windows security issue which has been around sinc…

The trivial fix is to execute not "git.exe" but "C:\Program Files\Git\bin\git.exe". With a configurable git binary

Of course that then leads you down the rabbit hole of whether the llm should exectute a known-good ripgrep, tree, etc. instead of depending on PATH resolution

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

#209
post #93

Earlier quoted context omitted.

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

Agreed, don't train fellow human beings (users) to follow, educate them.

"Make things as simple as possible, but no simpler." - commonly known quote.

We're making things so simple, the users don't get to have a proper chance at learning what's happening. Training people away from giving programs access, makes it opaque and dangerous. Unfortunately at the same time for non technology inclined users even Windows approach of file->Properties->Security visual UI proves challenging.

Post reply on HN