Developers using the **Cursor** integrated development environment (IDE) on Windows are exposed to a severe security flaw that enables arbitrary code execution simply by opening a crafted repository. The vulnerability, initially reported by AI security firm **Mindgard** on December 15, 2025, exploits **Cursor**'s behavior of executing a `git.exe` binary found in the project root without any prompts or warnings. ### The Exploit Mechanism When a project is loaded in **Cursor**, the IDE checks several locations for a Git binary. Crucially, one of these locations is the workspace itself. If a malicious `git.exe` file is present in the repository's root, **Cursor** will execute it as the logged-in user. This execution occurs with the user's full privileges, granting access to their source code, SSH keys, and cloud tokens. The malicious binary continues to run as long as the project remains open. **Mindgard** demonstrated this with a proof-of-concept using **Windows Calculator**, renamed `git.exe`, and committed to a repository. Upon opening the repository in **Cursor**, multiple instances of Calculator were spawned automatically.  ### Origin and Lack of Patch According to **Mindgard** founder **Peter Garraghan**, this behavior is not present in **Microsoft's VS Code**, from which **Cursor** forked. He suggests that **Cursor** likely passes an unqualified `git` command to **Windows'** `CreateProcess` function, allowing the operating system's search order to pick up the binary from the working directory. Despite the initial report in December 2025, and subsequent follow-ups, **Cursor** has not released a patch or an official advisory for this vulnerability. **Mindgard**'s most recent confirmation of the bug's persistence was on April 30, 2026, against **Cursor** version 3.2.16. The current release, 3.11, shipped on July 10, has not been explicitly tested for the fix.  ### Full Disclosure and Vendor Response After months of unacknowledged reports and a stalled disclosure process, **Mindgard** opted for full public disclosure on Tuesday, July 15. **Aaron Portnoy**, who authored **Mindgard**'s disclosure and has a significant background in vulnerability research (including running **Zero Day Initiative** and **Pwn2Own**), described full disclosure as the "nuclear option." **Cursor** responded publicly on July 15 via a forum announcement, rather than an official security advisory. The company stated the report was "out of scope" for their bug bounty program, citing a shared responsibility model where customers are accountable for the repositories and tools they open. While acknowledging a "process failure" in their communication with **Mindgard**, **Cursor**'s response did not commit to a fix or name any version where the behavior would be addressed. They noted the issue affects Windows only and relies on a `git.exe` in the project root. **Cursor** recommends using their "Workspace Trust" feature, which opens untrusted folders in a restricted mode. However, **Mindgard**'s report did not test whether the `git` probe runs *before* or *after* this trust check, leaving its effectiveness in question.  ### Broader Implications and Mitigations This class of vulnerability is not unique to **Cursor**. **Cymulate** previously published findings in June on similar issues across various AI tooling, where helper executables on Windows were resolved using the default search order, prioritizing the working directory. As there is no official patch from **Cursor**, users must implement workarounds: * **Managed Windows Fleets**: **Mindgard** suggests using **AppLocker** or **Windows App Control** to deny execution of `filename.exe` under workspace roots (e.g., `%USERPROFILE%\source\repos\*\filename.exe`). This should be path-based, not hash-based, as attacker binaries will vary. * **All Users**: Open untrusted repositories in a disposable virtual machine (VM) or **Windows Sandbox**. * **Pre-Opening Checks**: Before opening any cloned repository, manually inspect its root for suspicious executables like `git.exe`, `npx.exe`, `node.exe`, or `where.exe`, which typically have no place in a project root. This incident underscores the critical need for robust security practices in development environments, especially with the increasing adoption of AI-powered tools that might introduce new attack vectors.