Cursor IDE Flaw Lets Malicious Cloned Repos Execute Code on Windows

A critical unpatched vulnerability in the Cursor AI code editor allows attackers to achieve arbitrary code execution on Windows simply by tricking a developer into opening a cloned repository. Discovered by AI security firm Mindgard and reported to Cursor on December 15, 2025, the flaw exploits Cursor's Git binary lookup routine: when a project loads, the editor searches the workspace itself for a git.exe binary and executes whatever it finds, with no approval dialog, sandbox, or warning. The attacker-controlled binary then runs with the developer's full privileges, exposing source code, SSH keys, and cloud tokens. Mindgard's proof of concept used a renamed Windows Calculator binary (calc.exe as git.exe) committed to the repository root; opening the folder caused Calculator windows to stack up repeatedly as long as the project remained open.

The attack surface is alarmingly broad. Developers and AI coding agents clone unfamiliar repositories constantly, and a single malicious git.exe in the project root is enough to compromise the host. Mindgard confirmed the vulnerability as recently as April 30, 2026, against Cursor 3.2.16, though the latest tested version is unnamed in the write-up. As of July 15, The Hacker News found no advisory among Cursor's 33 published security bulletins covering the issue, and no CVE has been assigned. Whether the underlying mechanism involves Cursor's own PATH search or an unqualified invocation handed to Windows is not specified, but the practical effect is identical: from a repository anyone can publish to code running as the logged-in user, with no prior foothold required.

Because no patch is available, mitigation relies on workarounds. Mindgard recommends AppLocker or Windows App Control deny rules targeting executables under workspace paths such as %USERPROFILE%\source\repos\*\filename.exe, using path-based rather than hash-based rules since attacker binaries vary. Native Windows lacks a built-in mechanism to block a child process based solely on its parent, so parent-aware enforcement typically requires an EDR solution. Developers working with untrusted repositories should consider auditing cloned code locally and running a port scanner to detect any backdoors a malicious git.exe may have established, while teams concerned about credential exposure can use a password checker and a broader privacy checkup to assess what sensitive material may have been reachable from a compromised workstation. Cursor has not yet responded to requests to name any release that fixes the issue.