Cursor IDE Repo Flaw Enables RCE

Developers frequently clone repositories from unknown sources, assuming the environment remains isolated from their local machine. A severe security oversight in the Cursor IDE shatters this expectation, as opening a project folder on Windows triggers an automatic execution of any file named git.exe placed within the root directory.

Execution Without User Consent

When a developer opens a directory in Cursor, the application attempts to locate a Git binary to perform repository-level operations. If a malicious executable is present, the IDE runs it with the permissions of the logged-in user. This occurs without any warning, approval dialog, or interaction from the developer. Because the binary runs as the user, it gains full access to SSH keys, cloud tokens, and source code stored on the local system.

Timeline of Disclosure Failure

Security researchers at Mindgard first reported this vulnerability to Cursor on December 15, 2025. Despite repeated follow-ups throughout February, March, and April 2026, the company failed to address the issue. The researchers eventually opted for public disclosure after being ignored by the vendor.

• December 15, 2025: Mindgard reports the vulnerability to Cursor.
• January 20, 2026: HackerOne confirms receipt and reproduction of the report.
• April 30, 2026: Mindgard confirms the flaw persists in version 3.2.16.
• July 10, 2026: Cursor ships version 3.11, which remains unpatched.

The Industry-Wide Pattern

The issue is not unique to Cursor; other AI-driven development tools share similar vulnerabilities regarding search path resolution on Windows. Research from Cymulate confirms that tools like the GitHub Copilot CLI, the Gemini CLI, and the Codex desktop app exhibit identical behavior. Vendors have largely dismissed these reports, often arguing that a developer placing an untrusted binary in a directory implies a lack of threat. As noted by the security research team:

Full disclosure is the nuclear option of vulnerability disclosure

— Aaron Portnoy, researcher

Defensive Strategy and Risk

Because no patch currently exists, the responsibility for mitigation falls on the user or the organization's IT department. On managed Windows fleets, administrators should implement AppLocker or Windows App Control policies to block execution of binaries located within workspace directories. For individual developers, the most secure approach involves opening untrusted repositories only within a Windows Sandbox or a disposable virtual machine. Organizations must treat cloned code not as passive text, but as potentially active, executable content capable of compromising the entire development environment.