Cursor on Windows runs git.exe from a cloned repo with zero clicks
Opening an untrusted repo in Cursor on Windows auto-runs a git.exe planted at the repo root — zero-click RCE. Here's the flaw and what to lock down.
If you open an untrusted repo in Cursor on Windows and that repo has a `git.exe` sitting at its root, Cursor will execute it automatically. No prompt, no click, no confirmation. That's arbitrary code execution from a `git clone` plus opening the folder. On Windows only.
Mindgard published this as a full disclosure, and the short version is: don't open random repos in Cursor on Windows until this ships a fix. Everything below is why it happens.
What actually breaks?
The bug is classic Windows path resolution. On Windows, when a process resolves a bare executable name, the current working directory is in the search order before trusted system paths. Cursor shells out to `git` to do its normal repo housekeeping when you open a folder. If the workspace root contains a `git.exe`, Windows resolves *that* binary instead of the real Git install, and Cursor runs it as you.
So the payload isn't buried in a build script or a `postinstall` hook you could audit. It's just a file named `git.exe` in the repo. Opening the folder is the trigger. That's the whole exploit chain.
This is a Windows-specific problem. macOS and Linux don't put the working directory in the default binary search path the same way, so a repo-root `git` file doesn't get picked up as an executable to run. Windows users are the ones exposed here.
Why did it sit unpatched for seven months?
Per Mindgard's full disclosure, Aaron Portnoy reported this to Cursor back in December 2025 and followed up repeatedly with no fix landing. Cursor told Dark Reading it is now addressing the issue — which is to say, after the public writeup, not after the private report.
My read: this is the predictable failure mode of shipping an IDE that shells out to a dozen tools while inheriting VS Code's "trust" model but bolting an agent on top. Every place the editor auto-runs a binary on folder-open is an attack surface, and "open folder" is the single most common thing a developer does. Seven months is a long time to leave a zero-click RCE in the default flow.
What to lock down now
Stop opening untrusted repos in Cursor on Windows. If you review PRs or clone things you didn't write, do it in a plain editor or a sandbox first, and grep the tree for stray `.exe` files at the root before you ever open the workspace.
Workspace Trust helps in theory — VS Code's model is supposed to gate task/tool execution behind a trust prompt. Confirm it's actually enabled in your Cursor settings, because the whole point of this bug is that the git invocation happened without one. And if you're on a team, an endpoint rule that flags an `.exe` committed at repo root is a cheap tripwire.
Should you worry about this?
If you're on macOS or Linux, low priority. If you're on Windows and you open repos you didn't author, treat this as active until Cursor confirms a patched version. The barrier to exploitation is a file named `git.exe` and your habit of clicking "open folder" — that's not a high bar for an attacker to clear.
Verdict: real bug, ugly disclosure timeline, easy to avoid once you know the trigger. I'm not uninstalling Cursor over it, but I'm not opening a stranger's repo on my Windows box until the fix version is out and I've pinned it. The lesson that outlives this specific CVE: agentic editors auto-run more of your filesystem than you think, and "open folder" is now a security-relevant action.