Open a repository in Cursor on Windows and, if a file named git.exe is sitting in the project root, Cursor runs it. No click, no approval dialog, no warning that anything in the folder is about to execute. Whatever that binary does, it does as you, with your source, your SSH keys and your cloud tokens. Cursor keeps re-running it for as long as the project stays open. No prompt injection, no agent, no model in the loop, and no prior access to the machine: opening the folder is the entire exploit, and the result is arbitrary code execution as the logged-in user. AI security firm Mindgard reported the flaw to Cursor on December 15, 2025 and published full technical details on Tuesday, seven months later. There is still no patch, and Cursor has published no advisory for the issue. The mechanism takes about a sentence. Cursor checks several locations for a Git binary when a project loads, and one of them is the workspace itself. Process Monitor output in the write-up shows Cursor.exe spawning the repo-root binary with the command line git rev-parse --show-toplevel. That is the same repository-root probe Microsoft's VS Code docs describe. Whether Cursor searches those locations itself or hands Windows an unqualified git and lets the search order pick, the write-up does not say. Mindgard's proof of concept was Windows Calculator, renamed git.exe, and committed to the root. Clone, open, done. The screenshot shows Calculator windows stacking up on their own while the project sat open. The precondition sounds like the hard part: an attacker's binary, sitting in your project root. It is not. Cloning a stranger's repository is how binaries land on disk in the first place, and developers and their agents do it all day. The attacker needs no foothold to begin with.