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

51–60 of 222 posts

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

#51

Post by wxw »

> 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 that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.

Really unfortunate. I don't understand why there's such a lack of response on the Cursor side.

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

#52

Post by x3n0ph3n3 »

Illniyar wrote: post #21

It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months. But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, uns…

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?

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

#53

Post by shitter »

bragr wrote: post #49

I think this is slightly less of a Cursor bug than a bit of a Windows quirk: Windows searches the current working directory for executables before resorting to the path variable. I imagine a lot of stuff is vulnerable to such an "attack" on Windows.

Yeah, but you can easily mitigate it by searching for the real git in known system locations and using whatever you find there (or allowing the user to configure the path). I believe that's how VSCode does it

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

#54

Post by alansaber »

dclowd9901 wrote: post #31

This draws to mind the dialog that opens when you open a new project in Cursor (and VSCode too, I think), where the IDE asks the user if they trust the project they're opening. Is Cursor under the impression that this is sufficient security apparatus?

Startups historically are not the most security oriented

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

#55

Post by jwolfe »

x3n0ph3n3 wrote: post #52
Illniyar wrote: post #21

It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months. But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, uns…

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?

If bash placed the current directory in your PATH by default, then yes.

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

#56

Post by loumf »

x3n0ph3n3 wrote: post #52
Illniyar wrote: post #21

It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months. But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, uns…

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

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

#57

Post by shitter »

x3n0ph3n3 wrote: post #52
Illniyar wrote: post #21

It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months. But the example with calculator is a bit misleading I think, you'll have to have a malicious exe already in the system and downloaded, and if cursor tried to run my understanding is that ACL should immediately kick in and you'll be asked for permission to run a new, uns…

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?

I would file a CVE for any program that places untrusted content into PATH and invokes non-fully qualified executable names - not for the shell.

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

#58

Post by 4ndrewl »

AntonyGarand wrote: post #9
ajhenrydev wrote: post #8

This 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

The malicious payload can live on the remote: `git clone` a repo, open it with cursor, and you're compromised

It's curious the number of people here who can't link these two things.

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

#59

Post by firer »

orphereus wrote: post #37
firer wrote: post #28

All too common... It's sad yet understandable how a company would not prioritize security. At the same time, it's also understandable how a security start-up, upon (rightly) getting fed up waiting, decide to publicly disclose, as a way to scrape some PR out of the sunk cost. Public disclosure has a place. But if you truly care about helping, you could do more than bumping on HackerOne and messaging the CISO once on L…

This comment is so weird. It is so vague to me and feels so off, like an alien from Men in Black trying to pass as a human. How do they not truly care about helping? Also what sunk cost? What does that mean?

Hah, not trying to pass off as human. Just communicating with my fellow men in black ;)

To be as explicit as possible: whether disclosing this publicly actually did more good then harm is not that clear cut. Even if accounting for all the second order effects.

Regardless, as a business you'd still be compelled to publish, because you've already poured resources into this research, there's still a chance to gain something, and there is enough plausible deniability about your true priorities.

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

#60

Post by sofixa »

wxw wrote: 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…

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

Post reply on HN