Cursor Flaw Allows Malicious Compiled Repositories to Trigger Windows Code Execution

Open a repository in Cursor on Windows and, if a file named git.exe is located in the root of the project, Cursor runs it. No clicking, no confirmation dialog, no warning that something in the folder is about to be created.

Whatever this binary does, it does as you, with your source, your SSH keys and your cloud tokens. The cursor continues to recycle as long as the project remains open.

There is no instant injection, no agent, no model in the loop, and no pre-machine access: opening a folder is all exploit, and the result is to run code arbitrarily as a logged-in user.

AI security company Mindgard reported the bug to Cursor on December 15, 2025 and published the full technical details on Tuesday, seven months later. There is no patch yet, and Cursor has not published any advice on the issue.

The method of operation takes about a sentence. The cursor checks several places to find the Git binary when the project loads, and one of them is the workspace itself. Process Monitor output from writing shows Cursor.exe showing binary repo-root via command line git rev-parse –show-toplevel.

That’s the repository-root probe for the Microsoft VS Code documentation that explains. Whether the Cursor searches those places itself or gives Windows the wrong git and allows the search order to be selected, the write-up doesn’t say.

Mindgard’s proof of concept was the Windows Calculator, renamed git.exe, and committed to root. Clone, open, done. The screenshot shows the Calculator windows stacking on themselves while the project remains open.

The condition sounds like the hard part: the attacker’s binary, which sits at the root of your project. It is not. Merging a stranger’s cache is how binaries get to disk in the first place, and developers and their agents do it all day long. An attacker does not need to step to start. That’s the distance covered by this bug: from the repository anyone can publish code that works like you.

One limitation in evidence. Mindgard’s most recent confirmation is April 30, 2026, against Cursor 3.2.16, and the current release is 3.11, which ships on July 10. The write-up says the bug is still alive in the newest version it tested, but it doesn’t say which version.

Hacker News reviewed all 33 security advisories published by Cursor and found no entries covering the issue, as of July 15. No CVE given. We asked Cursor to name any releases that fix it, as well as Mindgard, the version it last tested. This story will be updated with any feedback.

What to do

There is no patch, so every option below is a workaround. On managed Windows ships, Mindgard suggests that AppLocker or Windows App Control override rules that block executables by name and path under the root of the workstation, on the lines %USERPROFILE%sourcerepos*filename.exe.

Rules of the road, not hashes; the attacker’s binaries differ by hash. Windows doesn’t have a standard built-in rule that only blocks a child process when a certain parent launches it, Strict notes, so enforcing the parent rule usually means EDR. Everyone else: open untrusted repositories in a disposable VM or Windows Sandbox.

Pair it with Cymulate’s advice to test a compiled repo or extracted archive before you open it. git.exe, npx.exe, node.exe, and where.exe have no business in the project root. What happened in the report is the whole story.

Cursor’s security page says the company accepts “vulnerability reports within 5 business days.” Mindgard’s first strong response came a month after a December report, from Cursor’s CISO, which explained that automation had failed to invite the company to HackerOne’s secret program.

The reposted report was closed the next day as informative and out of place, then reopened when Mindgard backtracked, and HackerOne reproduced it. HackerOne confirmed delivery on January 20. After that: review requests in February, March and April, and nothing back.

Cursor’s advisory record, read against Mindgard’s timeline, shows a process that worked for other researchers while Mindgard’s report was being prepared. On February 13, 2026, Cursor published GHSA-8pcm-8jpx-hv8r, a Git-hook sandbox vulnerability (CVE-2026-26268) was reported by Novee under the consolidated disclosure and fixed in Cursor 2.5. Three days later, on February 16, Mindgard requested an update on its own Git-related report. There is no answer. Two more Cursor advisories came out on July 14, the day the full disclosure came.

“Full disclosure is the nuclear option for risk disclosure,” Mindgard wrote, reserved for cases where all other methods have 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 tournaments.

Same Bug, Three Other Vendors

Mindgard isn’t the first company to figure this out, and it’s not the first to get Cursor’s response to it. In June, Cymulate published findings in a class common to all AI tools: on Windows, several of these tools solve exploits using an automatic search order, which checks the operating index before trusted system paths.

The GitHub Copilot CLI used the git.exe workspace initially, before the folder information was even displayed. The Gemini CLI does the same when launched on the workstation. The Codex desktop app has it in an open folder, like Cursor.

As of Cymulate’s writing on June 4, none of those vendors had posted a fix. GitHub checked its report and paid a dividend, then took it down. Google has acknowledged that the Gemini CLI findings were valid and is not issuing a patch. OpenAI closed the Codex report as Not Working, assuming that an attacker who could replace git.exe already has system access. That was not the reported situation. Cursor shut down Cymulate’s Cursor CLI report as information eight days in, citing that the malicious binary found “does not have an attack vector.”

That study revealed one correction. AWS assigned CVE-2026-10591 to its discovery of Kiro, called Cymulate and patched it in Kiro 0.11. But that was a different bug: a bug in writing the agent file that allowed .vscode/tasks.json to automatically extract to the open folder. No binary investing report has produced one.

Class comes before everything. The untrusted search mechanism is weak; planting a binary where the search will find it is an attack. Windows checking the current directory before %PATH% is what broke Git Credential Manager Core in 2020 (CVE-2020-26233): malicious git.exe at the top level of the repo, running instead of the original one during replication. Fixed in GCM 2.0.289.

Blaze Information Security’s PoC was then also renamed to git.exe. Six years on, the same trick falls against an IDE that does the investigation for you when you open a folder.

The four vendors are now exposed to a binary operating environment that runs on Windows as soon as a developer points the tool to the integrated environment. The two decided that it was not at all a risk; two admitted it was and, as of Cymulate’s June account, they had not moved anything. So the call falls to the defenders, and to Windows, which is safe to treat the combined cache as executable content, because that’s what it is.