Cursor runs a repository's own git.exe on Windows, and has done for months

Mindgard has published an unfixed flaw in Cursor on Windows: when the IDE loads a project it looks for git binaries in several locations, one of which is the current workspace, so a repository carrying a malicious `git.exe` in its root is executed automatically ^[1]. According to Mindgard there are no clicks, prompts, approval dialogs or warnings, and the result is arbitrary code execution ^[2]; the execution also recurs on a cadence rather than firing once ^[3].

That is the whole exploit. Mindgard notes it needs no prompt injection, no model manipulation, no jailbreak, no memory corruption and no sophisticated tradecraft, only a developer opening a project that contains the binary ^[4]. For anyone who clones repositories to read them, which is most of the job, the trust boundary has moved from "run the build" to "open the folder."

The blast radius is the reason to care. Mindgard cites Cursor's scale as more than 7 million active users, more than 1 million daily and more than 1 million paying, across more than 50,000 companies ^[5], against a reported market price of $60 billion ^[6].

The disclosure history is the part operators should read twice. Mindgard says it identified the issue on December 15, 2025 and reported it the same day, and multiple times since ^[7], and that more than six months and 197 or more new versions later the bug is still present in the latest version it tested ^[8]. Initial contact went to the security address in Cursor's published security.txt, followed by unanswered follow-ups and public attempts to find a contact ^[9]. Cursor's CISO eventually replied, attributing the gap to an internal automation failure that had stopped the expected HackerOne workflow, and invited Mindgard into the private bug bounty programme ^[10]. The resubmitted report was closed as Informative and out of scope; after a challenge, HackerOne reopened it, reproduced the issue and confirmed delivery to Cursor ^[11]. Mindgard says that after that, escalation through HackerOne and direct outreach to leadership both produced no response, while more than 70 versions shipped with the bug intact ^[12].

One caveat on the record: the post's own arithmetic does not reconcile. A December 15, 2025 discovery date sits awkwardly beside "more than six months," and the version counts of 197-plus and 70-plus appear in the same account without being squared ^[1]. We only have Mindgard's telling here; there is no Cursor statement in the material.

The interim advice is unglamorous. For managed Windows fleets, Mindgard suggests AppLocker or Windows App Control path-based deny rules scoped to workspace roots, such as `%USERPROFILE%\source\repos\*\filename.exe`, rather than hash rules, because attacker binaries vary by hash ^[13]. It also notes Windows has no general built-in way to block a child executable only when a specific parent launches it, so parent-aware enforcement needs EDR or a custom endpoint product ^[14]. For everyone else: open untrusted repositories in a VM, Windows Sandbox or another disposable environment, and do not rely on hash blocklists ^[15].

Watch for three things. Whether Cursor ships a release note that stops resolving git from workspace-relative paths, or at least prompts. Whether the HackerOne report changes state, given it has already been reopened and reproduced ^[11]. And whether your own endpoint tooling can see a git-named binary spawned from a repository root at all, because the path-based rule is a name filter and an attacker who renames the target loses nothing.