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. That is the distance this bug covers: from a repository anyone can publish to code running as you.
One limit on the evidence. Mindgard's most recent dated confirmation is April 30, 2026, against Cursor 3.2.16, and the current release is 3.11, shipped July 10. The write-up says the bug survives in the newest version it tested, but does not name that version.
The Hacker News reviewed all 33 security advisories Cursor has published and found no entry covering the issue, as of July 15. No CVE has been assigned. We asked Cursor to name any release that fixes it, and Mindgard, which version it last tested. This story will be updated with any response.
What to Do
There is no patch, so every option below is a workaround. On managed Windows fleets, Mindgard suggests AppLocker or Windows App Control deny rules that block the executable by name and path under workspace roots, along the lines of %USERPROFILE%\source\repos\*\filename.exe.
Path rules, not hashes; attacker binaries vary by hash. Windows has no general built-in rule that blocks a child process only when a specific parent launches it, the firm notes, so parent-aware enforcement generally means EDR. Everyone else: open untrusted repositories in a disposable VM or Windows Sandbox.
Pair it with Cymulate's advice to check a cloned repo or extracted archive before you open it. git.exe, npx.exe, node.exe, and where.exe have no business in a project root. What happened to the report is the rest of the story.
Cursor's security page says the company acknowledges "vulnerability reports within 5 business days." Mindgard's first substantive reply came a month after the December report, from Cursor's CISO, who explained that an automation had failed to invite the firm to the private HackerOne program.
The resubmitted report was closed the next day as informative and out of scope, then reopened once Mindgard pushed back, and HackerOne reproduced it. HackerOne confirmed delivery on January 20. After that: update requests in February, March and April, and nothing back.
Cursor's advisory record, read against Mindgard's timeline, shows the process working for other researchers while Mindgard's report sat. On February 13, 2026, Cursor published GHSA-8pcm-8jpx-hv8r, a Git-hook sandbox escape (CVE-2026-26268) reported by Novee under coordinated disclosure and fixed in Cursor 2.5. Three days later, on February 16, Mindgard asked for an update on its own Git-related report. No reply. Two more Cursor advisories went out on July 14, the day the full disclosure landed.
"Full disclosure is the nuclear option of vulnerability disclosure," Mindgard wrote, reserving it for cases where every other path has failed. The author, Aaron Portnoy, spent years on the other side of that trade: he ran the Zero Day Initiative and built the first six Pwn2Own contests.
The Same Bug, Three Other Vendors
Mindgard is not the first firm to find this, and not the first to get Cursor's answer on it. In June, Cymulate published findings on the identical class across AI tooling: on Windows, several of these tools resolve helper executables using the default search order, which checks the working directory before trusted system paths.
GitHub Copilot CLI ran a workspace git.exe at startup, before the folder-trust prompt was even shown. Gemini CLI did the same when launched from the workspace. The Codex desktop app did it on folder open, like Cursor.
As of Cymulate's June 4 write-up, not one of those vendors had shipped a fix. GitHub triaged its report and paid a bounty, then downgraded it to low. Google agreed the Gemini CLI finding was valid and released no patch. OpenAI closed the Codex report as Not Applicable, reasoning that an attacker who can replace git.exe already has system access. That was not the reported scenario. Cursor closed Cymulate's Cursor CLI report as Informative eight days in, on the grounds that findings requiring a malicious binary "lack an attack vector."
That research did produce one fix. AWS assigned CVE-2026-10591 for its Kiro finding, credited Cymulate and patched it in Kiro 0.11. But that was a different bug: an agent file-write flaw that let a poisoned .vscode/tasks.json auto-execute on folder open. None of the binary-planting reports had produced one.
The class predates all of it. An untrusted search path is the weakness; planting a binary where the search will find it is the attack. Windows checking the current directory ahead of %PATH% is what broke Git Credential Manager Core in 2020 (CVE-2020-26233): a malicious git.exe at a repo's top level, run instead of the real one during a recursive clone. Fixed in GCM 2.0.289.
Blaze Information Security's PoC back then was also calc.exe renamed git.exe. Six years on, the same trick lands against an IDE that runs the probe for you the moment you open the folder.
Four vendors have now been shown a workspace binary running itself on Windows as soon as a developer points the tool at a cloned repo. Two decided it was not a vulnerability at all; two agreed it was and, as of Cymulate's June account, had shipped nothing anyway. So the call falls to defenders, and on Windows, the safe one is to treat a cloned repository as executable content, because that is what it is.
