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

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

Why is cursor subsequently executing anything? Like what is this black magic they want to do? I want to know the decision tree here? Was this cursor coded?

I do not understand the point, btw vim has had similar issues with it executing stuff you might not expect by loading a file but it was obviously a vim feature with %{expr}. But why specifically git.exe , this seems like the most redundant bug cve which could have been trivially patched, who does this feature help exactly?

I am not really a user of cursor never used it for even a single day, but at this point I am curious why this exists...

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.

Would be nice if the timeline matched up with the text of the blog post (missing "HackerOne provides disclosure guidance").

> Most coordinated disclosures follow a familiar pattern:

> 1. A vulnerability is reported.

> 2. A dialogue begins.

> 3. Severity is discussed.

> 4. Engineering teams investigate.

> 5. Fixes are developed.

> 6. Users are protected.

> 7. Public disclosure follows.

8. The author prompts an LLM to write a blog post.

9. HN users are wasting time, unsure which parts of the post come from the actual prompt, and which are hallucinated world knowledge slop.

[flagged]

[dead]