Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution
A vulnerability in Cursor, a Git repository hosting platform for Windows, allows malicious cloned repositories to execute arbitrary code on the user's system. The flaw stems from Cursor's tendency to run a `git.exe` file found in a project root, regardless of whether it's a legitimate Git binary or a planted malicious one. Despite Mindgard's initial report and subsequent follow-ups, Cursor failed to issue a patch or advisory for over six months, and only downgraded the issue as ‘informative’ after repeated pressure. The issue has been replicated by other vendors, highlighting a broader problem with how AI tooling resolves helper executables on Windows.
A vulnerability in Cursor, a Git repository hosting platform for Windows, allows malicious cloned repositories to execute arbitrary code on the user’s system. The flaw stems from Cursor’s tendency to run a `git.exe` file found in a project root, regardless of whether it’s a legitimate Git binary or a planted malicious one. The vulnerability was initially reported by Mindgard on December 15, 2025, and despite repeated attempts to get a patch or advisory from Cursor, the issue remained unaddressed for over six months. The vulnerability was replicated by other vendors, including Cymulate, who found the same issue with AI tooling like GitHub Copilot CLI, Gemini CLI, and Codex, all of which resolve helper executables using the default search order, which checks the current directory before trusted system paths.
Mindgard’s report was initially closed as ‘informative’ and out of scope, only to be reopened after further pressure. Cursor’s security page states the company acknowledges ‘vulnerability reports within 5 business days,’ but Mindgard’s timeline shows a significant delay. The vulnerability has a long history, with a similar issue discovered in 2020 affecting Git Credential Manager Core (CVE-2020-26233), where a malicious `git.exe` at a repository’s top level would be executed instead of the real one during a recursive clone.
Despite the widespread replication of the issue and the lack of a timely response from Cursor, the company ultimately closed Cymulate’s report as ‘informative,’ arguing that findings requiring a malicious binary “lack an attack vector.” This highlights a broader problem with how AI tooling resolves helper executables on Windows, where a simple planted binary can lead to arbitrary code execution. The vulnerability has been replicated by several vendors, including GitHub Copilot CLI, Gemini CLI, and Codex, all of which resolve helper executables using the default search order, which checks the current directory before trusted system paths.
As of June 4, 2026, no vendor had shipped a fix, and GitHub triaged the 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. The call ultimately falls to defenders, and on Windows, the safe approach is to treat a cloned repository as executable content, because that is what it is.