Cursor Flaw Lets Malicious Cloned Repositories Execute Code on Windows

Opening a cloned repository in the Cursor AI code editor on Windows can be enough to execute arbitrary code, with no click, no approval prompt, and no warning that anything in the project folder is about to run.

How simple the trigger actually is

When Cursor loads a project, it checks several locations for a Git binary, including the workspace itself. If a file named git.exe sits in the repository root, Cursor runs it, and keeps re-running it for as long as the project stays open. AI security firm Mindgard demonstrated the flaw using Windows Calculator renamed to git.exe, committed to a repository's root. Clone the repository, open it in Cursor, and the calculator windows begin stacking on screen without any further action. No prompt injection, no AI agent, and no model involvement is needed. Opening the folder is the entire exploit.

Seven months of silence

Mindgard reported the flaw to Cursor on 15 December 2025 and published full technical details on 15 July 2026, after what it described as a breakdown in the disclosure process. A substantive reply came a month after the initial report, explaining that an automation had failed to route the submission correctly. The resubmitted report was closed as informative and out of scope, then reopened after pushback, with no further update despite follow-up requests in February, March, and April. Following the public disclosure, Cursor clarified that it considers the behavior out of scope for its vulnerability program under a shared responsibility model, noting that enabling its built-in 'Workspace Trust' feature mitigates the automatic execution risk. There is still no official vendor patch or CVE assigned as of publication.

This is not just a Cursor problem

Separate research from Cymulate published in June found the identical vulnerability class affecting other AI coding tools. GitHub Copilot CLI ran a workspace git.exe at startup, before its own folder trust prompt even appeared. Gemini CLI did the same when launched from an untrusted workspace, and OpenAI's Codex desktop app executed a workspace binary on folder open. Of four vendors shown the same underlying flaw, two declined to treat it as a genuine vulnerability at all. Only AWS fixed anything, and that was a related but distinct bug in its Kiro tool. This pattern connects directly to GhostCommit, the image based prompt injection technique we covered targeting AI coding agents, and to SkillCloak, the research showing malicious AI agent skills evading static scanners. Across all three, the common thread is the same: the AI coding tool ecosystem is accumulating a body of unpatched, cross-vendor security debt faster than vendors are addressing it.

An old bug in a new wrapper

The underlying weakness, Windows checking the current directory ahead of trusted system paths when resolving an unqualified binary name, is not new. It broke Git Credential Manager Core in 2020 under a nearly identical proof of concept, also a renamed calc.exe. Six years later, the same trick works against AI coding tools that automatically probe for Git binaries the moment a folder opens.

What to do

There is no vendor fix, so every mitigation here is a workaround. Organisations managing Windows developer fleets should consider AppLocker or Windows App Control deny rules blocking executables by name and path under workspace roots, since attacker binaries vary by hash but not by the paths they exploit. Individual developers should treat cloned repositories as executable content rather than passive source code, opening untrusted repositories inside a disposable virtual machine or Windows Sandbox rather than a primary development environment. This guidance sits alongside the broader posture shift we described in our research on agentic AI rewriting enterprise attack surfaces: security teams need visibility into AI coding tools running inside their organisation regardless of whether a formal vulnerability disclosure process has run its course.