Critical Cursor 0-Day Flaw Allows Malicious Git Repos to Trigger Automatic Windows Code Execution

A critical unpatched vulnerability in Cursor, the popular AI-powered code editor used by over 7 million developers, allows attackers to achieve arbitrary code execution on Windows systems.

Simply opening a malicious repository is sufficient to trigger this execution path, requiring no user clicks, prompt confirmations, or authorization approvals.

The flaw was discovered by security firm Mindgard on December 15, 2025, and reported to Cursor’s security team on the same day.

Despite 197 subsequent version releases, the vulnerability remains present in the latest tested build, prompting Mindgard to go public after seven months of vendor silence.

Critical Cursor 0-Day Flaw

The vulnerability stems from how Cursor resolves Git binaries when loading a development project. Among the locations Cursor searches is the workspace root itself.

If an attacker plants a malicious file named git.exe in that root directory, Cursor executes it automatically as part of its normal path resolution routine. Because the editor performs this search implicitly, it triggers execution without any security prompt or user warning.

The structural impact of this automatic execution loop is analyzed in the official Mindgard zero-day report. During testing, Mindgard demonstrated this issue using a renamed Windows Calculator binary as a harmless proof-of-concept.

Simply opening the directory project in Cursor caused repeated executions of the binary, spawning multiple Calculator instances over time as the IDE re-invoked the file during routine background execution.

Sysinternals Process Monitor logs confirmed that the parent process Cursor.exe spawned the planted binary via a standard git rev-parse --show-toplevel query, last verified on Cursor version 3.2.16.

In a real-world scenario, this Calculator executable would be replaced with an active threat vector such as a ransomware loader, credential harvester, or keylogger operating silently under the victim’s current privilege level.

Mindgard’s outreach followed standard industry-coordinated disclosure protocols:

• December 15, 2025: Initial vulnerability report sent via Cursor’s published security.txt email, followed by repeated status requests.
• January 2026: After receiving no response, Mindgard initiated public LinkedIn outreach to locate a valid contact. Cursor’s CISO responded, attributing the delay to a broken HackerOne automation error, and manually invited Mindgard into their private bounty program.
• Bounty Evaluation: The report was initially closed as “Informative” and out of scope. This assessment was reversed only after Mindgard challenged the ruling and HackerOne triage staff successfully reproduced the bug.
• January – June 2026: Mindgard sent multiple status requests through HackerOne and made direct attempts to contact Cursor leadership. All messages went unanswered, even as the vendor continued shipping dozens of new production releases.

This lengthy delay in prioritizing critical development environment vulnerabilities echoes wider industry concerns regarding how unsecured third-party scripts can compromise developer endpoints.

Because there is currently no official vendor patch available, administrators and consumer users must rely on compensating security controls to limit their exposure.

Enterprise security groups managing Windows endpoints should deploy path-based deny rules rather than hash-based controls:

• AppLocker / Windows App Control: Create path deny rules targeting workspace directories (e.g., %USERPROFILE%sourcerepos*git.exe). Since attacker-supplied binaries vary by hash, block rules must target the file path rather than the file signature.
• EDR Integration: Because Windows lacks native, parent-process-aware application blocking, full mitigation requires configuring specialized endpoint detection and response (EDR) rule overrides to monitor child processes of Cursor.exe.

Individual developers should take strict containment precautions when dealing with external repositories:

• Sandbox Isolation: Avoid opening untrusted or newly cloned repositories directly on a host operating system. Open projects exclusively within a disposable Virtual Machine (VM) or a Windows Sandbox session until a formal security patch is shipped.
• Process Auditing: Monitor active task managers for unauthorized child processes. Security teams should proactively audit endpoints to defend against untrusted execution layers that might bypass traditional host isolation.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.