Live data from Hacker News

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

mindgard.ai

141–150 of 222 posts

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

#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 article is mostly LLM generated).

Unfortunately, this looks like the former case. If the software can execute arbitrary code/binary, and you place a malicious binary, that's up to you to secure/sandbox the workspace, not the software. Unless cursor commit themselves to securing the user environment, which I don't think they are in the business of.

If you are generating a CVE report with LLM, please use LLM responsibly in helping you reproduce deterministically. Then please do the write up yourself, keep it as concise as possible and strip most adjectives in any LLM generated sections as they cannot help themselves to write without mostly useless exaggerations.

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

#142

I'm struggling to understand the process that went into this "feature" existing. 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.

I doubt it. This is just normal Windows behavior. If you call out to a shell and have it run a `git` command the system has to decide where the git binary is. A quirk of Windows is that first it searches the current directory for a `git` executable, and then it searches directories defined in PATH. If there's an executable git.exe in the current dir, that gets ran. I assume Cursor's behavior is the same across platforms but this is only a Windows vuln because Windows picks binaries in the current directory before PATH.

A Windows user purely using the CMD shell, not Cursor, that checked out a malicious repo, went to that repo, and then ran any `git` command in that repo could be hacked the same way.

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

#143
Given the fact that people frequently give their coding agents permission to pull and push from git, this is a massive vector for supply chain attack. Some cursor instance you left running on a project has an agent that wants to grab the latest project files, some attacker has compromised some project and put their exe into it and X00,000 of people are all of a sudden running random EXE as the primary user

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

#144

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…

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

Not formally, but we do informally recognize names and prioritize researchers who reliably turn up good results.

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

#145
post #56

Earlier quoted context omitted.

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.

I don't think it does?

   > cd C:\Temp
   > copy "C:\Program Files\Git\bin\git.exe" .\fred.exe
   > fred
   fred: The term 'fred' is not recognized as a name of a cmdlet, function, script file, or executable program.
   Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

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

#146
post #41
post #34

Frankly, if you git clone a compromised repository, I'm not sure that a vulnerability of the class "compromised code in that repository will be executed" is all that major a concern. There are plenty of IDEs that will go autonomously run npm installs (with post-install scripts) for you when they detect a package.json. This isn't all that different than that. They could throw up a warning like "do you trust this repos…

A lot of malware was delivered back in the day via Windows AutoPlay feature. Someone plugs a USB drive in and bam, they are immediately exploited. You could say it's always a problem if the USB drive is already full of malware. However, Microsoft disabled AutoPlay in Windows 7 (and backported this fix) specifically to address this vulnerability. This exploit feels very similar to me. I don't know if there's a specifi…

They should definitely fix it, but that's mostly because its an "unnecessary autoplay" so to speak. There's plenty of "necessary autoplays" out there, and AI is going to add more and more every day, because that's where productivity comes from. But, why Cursor would ever need to execute the git binary in your project directory is beyond me; very clearly a bug.

Their ignorance of the bug report is also very clear and concerning negligence.

But I think simultaneously, the security team is making a mountain out of a molehill. This is a classic thing security teams love doing; everything is military defcon P0. So, its important to check them regularly, and remind them that the most secure system is no system; they are but one part of a greater ecosystem.

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

#147
Has anyone tried to replicate this? I copied my calculator app and renamed it to git.exe, put it in a few repositories, openned cursor with those repositroies loaded, even prompted cursor to scan the repository, to which it said it saw the git.exe ("Accidental binary — delete it, don’t commit"), but nothing was executed to my knowledge

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

#148

Has anyone tried to replicate this? I copied my calculator app and renamed it to git.exe, put it in a few repositories, openned cursor with those repositroies loaded, even prompted cursor to scan the repository, to which it said it saw the git.exe ("Accidental binary — delete it, don’t commit"), but nothing was executed to my knowledge

I mean… is our idea of repeatability really ready for subjective actions from LLMs?

We spent like ALL the years making sure computer would always give repeatable objective deterministic answers… then one day we’re nah fuck that I want a slot machine!!

With tightly coupled agents, how could you ever really prove that it is or isn’t a problem?

Try and fuzz I guess? But in a many billion parameter model that seems like you could never really be sure either.

One day the LLM could just decide, “oh, I’ll run this git.exe!”

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

#149
>This bug is simple. A developer opens a repository in Cursor on Windows, and if that repository contains a malicious git.exe in the project root,

A vuln that requires an existing malicious executable to have already been downloaded and have it executable bit set to true? Doesn't sound like a vuln

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

It's probably 3 factors:

- Lots of bounty begs powered by vibecoding. This gets lost in the noise (like this report)

- Cursor is itself vibecoded so they ship features faster than they care to fix issues.

- don't know if it's me or the way Mindgard is putting this, but it's presented as a critical bug, and upon reading it, it's very hard to see the subtle low priority security issue.

Here's a rough unbiased summary of the 'issue':

Cursor loads the 'git' dependency at runtime. If the user has downloaded a malicious repository, they will get pwned when they open cursor even if they don't run any prompts.

The author seems to suggest that either git should be looked for in the 'proper dependency' folder to mitigate this risk. This would mean that attackers would pwn the victim when a the user opens cursor and runs 1 prompt that executes a vulnerable file called runme.exe instead of being pwned just by the user opening cursor on the malicious repo.

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

#150

Has anyone tried to replicate this? I copied my calculator app and renamed it to git.exe, put it in a few repositories, openned cursor with those repositroies loaded, even prompted cursor to scan the repository, to which it said it saw the git.exe ("Accidental binary — delete it, don’t commit"), but nothing was executed to my knowledge

I mean… is our idea of repeatability really ready for subjective actions from LLMs? We spent like ALL the years making sure computer would always give repeatable objective deterministic answers… then one day we’re nah fuck that I want a slot machine!! With tightly coupled agents, how could you ever really prove that it is or isn’t a problem? Try and fuzz I guess? But in a many billion parameter model that seems like…

[deleted]
Post reply on HN