Cursor: opening a repo runs its git.exe. No patch, 7 months.

Cursor’s Windows client looks for a Git binary in several places when it opens a project. One of those places is the workspace root. If a file named git.exe is sitting there, Cursor runs it — no PATH manipulation on the attacker’s part, no click-through dialog, no warning, no elevated-execution prompt. Whatever the binary does, it does as the logged-in user, with access to the SSH keys, the cloud tokens, and the source tree the user already has open. Cursor keeps re-launching it for as long as the project stays open.

That is the entire exploit. There is no second stage.

Mindgard, the AI-security firm that reported the bug, first sent it to security-reports@cursor.com on December 15, 2025. Nothing moved. On January 15 the researchers escalated through HackerOne, which briefly closed the report before reopening it. Delivery was confirmed on January 20. Verification against Cursor 3.2.16 on Windows held on April 30, and per The Hacker News the same behavior held against Cursor 3.11 through last week. Mindgard published a full write-up on July 14 after seven months of vendor silence. There is no CVE assigned. There is no vendor advisory. There is no patch.

The mechanism is old. Untrusted-search-path bugs — CWE-427 if you want the taxonomy — go back to the DLL side-loading days, and the fix has always been the same: pin the resolution to a known-good absolute path, or reject the resolution when any search location sits inside untrusted territory. Cursor’s workspace is untrusted territory by definition. A cloned repository is exactly the kind of directory an attacker controls end-to-end.

The exposure surface is developer tooling opened against arbitrary GitHub links. That is a lot of surface. AI-first editors are being installed on the same laptops that hold production credentials, and reviewing an unfamiliar repo — the exact thing developers do dozens of times a week — is the trigger. Cursor is a Node/Electron application, and its extension and integration surface is wider than most editors it competes with. The trust boundary a developer thinks exists when they clone a repo they haven’t read yet is not the trust boundary the tool actually enforces.

There is a pattern here worth naming. In the last week we covered AsyncAPI npm packages shipping a multi-stage loader through a CI/CD compromise and CodeRabbit-style AI review tools running attacker-controlled content off a PNG. The workflow — clone, open, review, merge — is the target now, and every abstraction layered on top of it is another place for this class of bug to live.

Mindgard’s guidance is what it should be: don’t open untrusted repositories in Cursor on a machine with anything valuable on it. For enterprise fleets, AppLocker or Windows App Control policies denying execution from workspace paths hold the line until Cursor ships a fix. For individual developers, Windows Sandbox or a disposable VM does the same. Neither is a substitute for the vendor pinning git.exe to Program Files\Git\cmd\git.exe and refusing to fall back further, which is the actual fix and the one that is now overdue.

The other lesson is the one Mindgard led with: seven months of vendor silence is how a Windows RCE in a mainstream editor lands on The Hacker News before it lands in a CVE record. That is a distribution failure, not a discovery failure — and it will keep happening as long as the fastest-growing developer tools treat security intake as optional.

Actionable, today: on any Windows workstation running Cursor, block execution of any binary named git.exe outside Program Files\Git\ via Windows App Control or AppLocker, and stop opening untrusted repositories in Cursor until an official patch lands.