The Cursor Zero-Day That Sat Through 70 Versions

Note : This piece is a breakdown of original research disclosed by Mindgard, written by Aaron Portnoy. The full disclosure, timeline, and procmon logs are on the Mindgard blog. This article exists to make the finding readable for builders and founders who don't read disclosure writeups.

A researcher renamed Windows Calculator to git.exe, dropped it in a folder, and opened that folder in Cursor. Calculator opened. He didn't click anything.

That's the whole proof of concept. One file. One rename. One folder open. Code execution.

Quick version: Cursor on Windows runs any git.exe it finds in the root of a repo you open. No click, no trust prompt. Arbitrary code execution as your user. Cursor's response, via HackerOne, was to close it as "informative, out of scope." Whether or not they call it a bug, here's how it works, how to reproduce it, and what a real payload looks like. Until it's acknowledged, open untrusted repos in a VM or Windows Sandbox, not your daily driver.

The PoC

The proof of concept is Windows Calculator. That's the whole payload in the demo, because the point is execution, not the payload.

Here's the reproduction, step by step, on a clean Windows machine with Cursor installed:

Make a folder. git init it, or don't. Cursor doesn't care.
Copy C:\Windows\System32\calc.exe into that folder and rename it to git.exe.
Open the folder in Cursor.
Calculator opens. Every time.

That's it. No click. No "do you trust this workspace?" prompt. No banner.

The executable runs before you'd have a chance to inspect anything.

If you want to confirm you're seeing what you think you're seeing, swap calc.exe for a payload that pops a notepad with your username, or writes a file to C:\Users\Public\proof.txt. You'll see the file. That's RCE.

Is it even a bug?

This is the question a casual reader would actually ask, so let's answer it honestly.

Cursor's apparent position: closed as "informative, out of scope." In bounty terms, that means "we see it, but we don't think it counts as a vulnerability."

The counter: arbitrary code execution from opening a repo. No user action. On the default install. As the logged-in user, with all their privileges.

You can argue the classification. You can't argue the file ran.

Call it a bug, call it a bad default, call it a design oversight. The behaviour is what it is. The rest of this piece is about the behaviour, and you can decide what label it earns.

The mechanism (and why nobody caught it)

The mechanism is mundane, which is why it's been sitting there for so long.

When Cursor opens a repo on Windows, it shells out to git for source-control operations. On Windows, CreateProcess with a bare executable name resolves in a fixed order: the application's own directory, the current working directory, the system directories, then PATH.

Because Cursor sets the working directory to the repo root when it launches git, and because the repo root comes before system PATH in that search order, a git.exe sitting in the repo root wins over the real Git installed in C:\Program Files\Git.

This is the same "current directory first" behaviour that has bitten Windows tooling for two decades. It's not exotic. It's the reason PATHEXT and safe process creation get taught in every Windows internals course.

Which is why most Windows tooling stopped doing it twenty years ago. Whether that makes it a vulnerability or just a bad default is the argument Cursor is having.

A couple of details make it worse.

It's Windows-only, so most of the security community (which lives on macOS) never hits it.

And VS Code's "Workspace Trust" prompt exists precisely because git can be used in untrusted code, but Cursor's git invocation fires before that trust decision could gate it. The prompt that would have saved you runs after the damage.

What runs when you're not looking

Calculator is the demo. The actual attack is whatever you'd run if you had one process execution on a developer's machine as their user.

Imagine you find a cool open-source repo on GitHub. You clone it, open it in Cursor to poke around. In the three seconds before your editor even finishes loading, a script has already copied your SSH keys, your AWS credentials, and your Git token into a zip file and sent it somewhere. You close the repo. The damage is done.

A few shapes I'd expect in the wild:

Credential grab. A short PowerShell one-liner that zips .ssh\, .aws\, .git-credentials, and the browser cookie stores, then exfils over DNS or HTTPS. Total time: under 3 seconds. Most developers have at least one cloud credential and one Git token on disk.

Dropper. Stage 1 fetches Stage 2 from a CDN, runs it, exits. Stage 2 is a backdoor that lives in %APPDATA% and adds a scheduled task for persistence. The developer sees a Cursor window and nothing else.

Supply-chain foothold. If the developer has access to a production repo, the payload adds a malicious commit or a CI secret to the next push. The blast radius is now the company, not the laptop.

The reason this is high-impact isn't the bug. It's the population. Cursor is installed on a lot of developer machines, those machines tend to have source code, cloud credentials, and deploy access. One file in one repo is a very cheap lever for a very long reach.

If you run detection or IR and want to know whether this has already happened in your environment, the signal is small but clean.

Sysmon Event ID 1 (process creation) where the parent is Cursor.exe (or the Cursor helper that shells to git) and the child is git.exe with an image path that is not under C:\Program Files\Git\. The legitimate git lives there. A git.exe anywhere else, spawned by Cursor, is the bug firing.

A one-line hunt:

ProcessCreation | where ParentImage endswith "Cursor.exe" | where Image endswith "git.exe" | where Image !startswith @"C:\Program Files\Git"

Windows Defender for Endpoint, Sentinel, and Elastic Endpoint all catch this with a basic rule. Most teams don't have the rule written, because nobody assumed the editor would resolve git from the repo root.

That assumption is the thing to update.

Seven months, and not even acknowledged as a bug

This is the part where the classification matters more than the timeline. If you don't count it as a bug, you don't route it, you don't fix it, and 70 versions ship underneath it.

The researcher (Mineguard) reported the bug to Cursor's published security contact. No confirmation. Follow-ups went nowhere. Public outreach was attempted. Eventually the Cursor CISO replied and admitted an internal automation failure had broken their HackerOne workflow. The researcher was invited into a private bounty program and resubmitted.

HackerOne closed it as "informative, out of scope." The researcher pushed back. HackerOne reopened it, reproduced the issue, and confirmed the details had reached Cursor.

Then everything stopped. Update requests went unanswered. Escalation through HackerOne produced nothing useful. Direct outreach to Cursor leadership produced the same silence.

While this was happening, Cursor shipped. More than 70 versions. Features, launches, announcements. The vulnerability stayed exactly where it was.

A zero-day this trivial sitting through 70 releases is not a hard-fix problem. It is a priority problem.

Then the researcher went public. That's when this story stopped being a private ticket and started being everyone's problem.

Why this is bigger than Cursor

The pattern is the thing, not the product.

AI-assisted IDEs are not editors anymore. They run code, resolve paths, execute hooks and tool binaries, and inherit the trust of the machine they're installed on.

Most of the security conversation about AI coding tools focuses on what the model writes: does it leak secrets, does it generate vulnerable code, does it exfiltrate your codebase. Those matter. But the IDE itself, the thing that runs the model, is software running on your machine with your privileges.

If a vendor can sit on a one-file RCE for seven months because they don't classify it as a bug, the question isn't "is this bug fixed." It's "what else in their queue isn't counted as a bug."

Reference

Link the blog: https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left