"Open a repository in Cursor on Windows and, if a file named git.exe is sitting in the project root, Cursor runs it." — from Mindgard's write-up.
How the flaw works: an untrusted-search-path turned into code execution
Mindgard's proof-of-concept is stark and simple: when Cursor opens a project on Windows it probes for a Git binary and, if it finds an executable called git.exe in the repository root, Cursor launches it without prompt. Process Monitor output in the write-up shows Cursor.exe spawning the repo-root binary with the command line git rev-parse --show-toplevel. The binary runs as the logged-in user and Cursor keeps re-running it for as long as the project remains open.
The exploit requires no prior access to the victim machine, no prompt injection, no model in the loop and no clicks: cloning a repository that contains a malicious git.exe into the developer's workspace is sufficient. Mindgard's proof-of-concept simply renamed Windows Calculator to git.exe, committed it to the repo root, cloned the repository and opened it; Calculator windows then spawned while the project sat open.
Mindgard's disclosure timeline and Cursor's handling
Mindgard reported the flaw to Cursor on December 15, 2025. According to the account in the write-up, the firm published full technical details on Tuesday, July 14, 2026 — seven months after the initial report. Mindgard's most recent dated confirmation is April 30, 2026, against Cursor 3.2.16; Cursor's current release, the write-up says, is 3.11, shipped July 10, 2026. The write-up says the bug survives in the newest version it tested but does not name that version.
Mindgard describes an uneven disclosure process. Cursor's security page promises to acknowledge "vulnerability reports within 5 business days." Mindgard reports its first substantive reply came a month after the December report from Cursor's CISO, explaining that an automation had failed to invite the firm to a private HackerOne program. The resubmitted report was closed the next day as Informative and Out of Scope, then reopened after pushback; HackerOne reproduced the issue and confirmed delivery on January 20. Mindgard says it received update requests in February, March and April, and then nothing back. As of July 15, The Hacker News review of Cursor's 33 published advisories found no entry covering this issue, and no CVE has been assigned.
The same class of bug across other AI tooling
Cymulate's June 4 write-up found the same pattern in multiple AI-related tools. The report said GitHub Copilot CLI ran a workspace git.exe at startup before a folder-trust prompt appeared, Gemini CLI behaved the same when launched from a workspace, and the Codex desktop app ran a workspace binary on folder open. As of Cymulate's account, none of those vendors had shipped a fix: GitHub triaged the report, paid a bounty and downgraded it to low; Google agreed the Gemini CLI finding was valid and released no patch; OpenAI closed the Codex report as Not Applicable on the grounds that an attacker who can replace git.exe already has system access — a conclusion Cymulate disputes.
One vendor did patch a related but distinct issue: AWS assigned CVE-2026-10591, credited Cymulate and patched Kiro 0.11 for an agent file-write flaw that let a poisoned .vscode/tasks.json auto-execute on folder open. But that was a different vulnerability; the workspace-binary planting reports across vendors remained without vendor patches as of the accounts in June and July.
Practical mitigations for Windows users and managed fleets
There is no vendor patch reported by Cursor in the public record as of July 15, so Mindgard's recommendations are workarounds. On managed Windows fleets the firm suggests AppLocker or Windows App Control deny rules that block executables by name and path under workspace roots — for example, rules along the lines of %USERPROFILE%\source\repos\*\filename.exe. Mindgard emphasizes path rules rather than hashes because attacker binaries vary by hash.
Because Windows lacks a built-in way to block a child process only when a specific parent launches it, the write-up notes that parent-aware enforcement generally requires EDR. For individual developers, Mindgard recommends opening untrusted repositories in a disposable VM or Windows Sandbox. Cymulate's guidance to inspect a cloned repository or an extracted archive before opening it is complementary: files such as git.exe, npx.exe, node.exe, and where.exe "have no business in a project root," the write-up warns.
What this means for developers, security teams, and tool vendors
- Developers: Treat cloned repositories as executable content. The exploit shows how a seemingly benign repo can carry a binary that runs automatically when a workspace opens.
- Security teams and IT operations: Where patching is not yet available, deploy AppLocker or App Control path rules, use EDR for parent-aware process controls, and consider sandboxed workflows for untrusted code.
- Tool vendors and bug-bounty programs: The pattern — Windows' default search order allowing the working directory to be preferred over system paths — has been reported across multiple vendors and previously produced CVE-2020-26233 for Git Credential Manager Core in 2020. The write-ups show the recurrence of an old weakness and, in some cases, differing vendor responses to reports.
Until vendors ship fixes and publish advisories, the only reliable defense is operational: assume a cloned repository can be executable content, inspect repository roots for unexpected binaries before opening them, and apply platform controls that prevent workspace-root executables from running under normal developer sessions. Mindgard framed full disclosure as a last resort and published after months of interaction; the record on Cursor shows no advisory or CVE as of July 15, 2026.
