Cursor IDE Arbitrary Code Execution Vulnerability

Arbitrary Code Execution via Malicious Git Binaries

Cursor IDE contains a vulnerability that allows for arbitrary code execution (ACE) on Windows systems without user interaction. When Cursor loads a project, it searches for Git binaries in several locations, including the current workspace root. If a repository contains a malicious executable named git.exe in its root directory, Cursor will automatically execute it as part of its path resolution logic.

This execution occurs repeatedly on a cadence while the project remains open, rather than as a one-time event. The vulnerability does not require prompt injection, memory corruption, or complex exploitation chains; it simply requires the user to open a project containing the planted binary.

Technical Details and Proof of Concept

The vulnerability stems from Cursor's path resolution logic for Git. The IDE attempts to locate git.exe to perform version control operations. Because it checks the workspace root before or alongside system paths, an attacker-supplied binary in the project folder takes precedence.

Proof of Concept

Mindgard demonstrated this vulnerability by renaming the Windows Calculator application to git.exe and placing it in a repository root. Upon opening the repository in Cursor, the IDE automatically launched multiple instances of the Calculator application without any user prompts or approval dialogs.

Process Execution

Sysinternals process monitor logs confirm that Cursor.exe creates a process for the malicious binary. For example, the logs show Cursor attempting to run git rev-parse --show-toplevel using the binary found in the workspace root:

4:25:12.6209706 PM Cursor.exe 54880 Process Create c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe SUCCESS PID: 48972, Command line: git rev-parse --show-toplevel

Mitigation and Protection

Until a formal patch is released by the Cursor team, users and administrators should implement the following protections:

For Enterprise and Managed Windows Systems

Administrators should use AppLocker or Windows App Control policies to deny the execution of executables from developer workspace directories. Path-based deny rules are recommended over hash-based rules because attacker binaries will vary. A suggested rule scope is: %USERPROFILE%\source\repos\*\filename.exe.

For Individual Users

Users should open untrusted repositories only within isolated environments, such as a Virtual Machine (VM) or Windows Sandbox. Relying on file hash blocklists is insufficient for this specific threat.

Disclosure Timeline and Vendor Response

Mindgard first identified and reported the vulnerability on December 15, 2025. Despite repeated attempts to communicate through official security channels, HackerOne, and direct outreach to leadership, the issue remained unpatched for over seven months and across more than 197 versions of the software.

Date	Action
Dec 15, 2025	Vulnerability discovered and reported to security-reports@cursor.com
Jan 15, 2026	Vulnerability submitted via HackerOne after CISO intervention
Jan 16, 2026	Report reopened by HackerOne after successful reproduction
Jan 20, 2026	HackerOne confirms delivery of report to Cursor
Jun 1, 2026	Mindgard informs HackerOne of intent to disclose publicly
Jul 14, 2026	Full public disclosure published

Community Perspectives and Counterpoints

Following the disclosure, the technical community raised several points regarding the severity and nature of the vulnerability:

• Pre-existing Compromise: Some argue that if an attacker can already place a file in a user's filesystem (via a git clone of a malicious repo), the system is already partially compromised, comparing it to malicious npm install scripts.
• OS-Level Behavior: Some users suggest this is a Windows-specific quirk where the OS searches the current working directory for executables before the system PATH, making many Windows applications potentially vulnerable to similar attacks.
• OS Protections: There is debate over whether Access Control Lists (ACLs) or antivirus software would trigger warnings for unsigned binaries, potentially mitigating the impact for some users.
• Trust Models: Questions were raised regarding whether Cursor's existing "Trust Workspace" dialog is intended to cover this risk, or if the Git lookup occurs before that check is performed.