Cursor 0day: Automatic Execution of git.exe in Repository Roots and the Failure of Disclosure

Cursor 0‑day allows automatic execution of a malicious git.exe placed in a repository root

Takeaway: Cursor on Windows automatically runs any git.exe found in the opened project’s root directory, giving an attacker who can plant that file arbitrary code execution without user interaction. The flaw has been known since December 2025, remains unfixed in the latest tested version, and the vendor has not responded to multiple disclosure attempts.

What the vulnerability does

When a developer opens a project, Cursor searches for Git binaries in several locations, including the workspace itself. If a file named git.exe exists in the repository root, Cursor launches it as part of its path‑resolution logic. The execution happens silently—no prompts, dialogs, or warnings are shown. The binary is invoked repeatedly while the project stays open, as demonstrated by a proof‑of‑concept that renamed the Windows Calculator (calc.exe) to git.exe and caused dozens of calculator windows to appear.

The result is arbitrary code execution under the current user’s privileges. The attack surface is minimal: an attacker only needs to place a malicious executable named git.exe in the repository that a developer will open with Cursor.

Evidence of exploitation

  • Process monitor log (Cursor 3.2.16, Windows, 30 Apr 2026):
    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 \
"C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe"
  • The same binary was launched repeatedly, confirming that Cursor re‑executes the file on a cadence while the workspace remains open.

Why the bug matters

  • Scale: Cursor reports > 7 million active users, > 1 million daily users, and > 1 million paying customers across > 50 000 companies. A remote code execution (RCE) flaw in such a widely deployed IDE represents a massive attack surface.
  • Impact: The attacker runs code with the same privileges as the developer, potentially stealing credentials, exfiltrating source code, or installing persistent malware.
  • Simplicity: No complex exploit chain, prompt injection, or model manipulation is required—just opening a repository.

Mitigation steps for users

Enterprise or managed Windows environments

  • Deploy AppLocker or Windows App Control policies that deny execution of git.exe (or any executable) located in typical workspace paths, e.g.:
    %USERPROFILE%\source\repos\*\git.exe
  • Prefer path‑based deny rules over hash‑based ones because attackers can vary the binary’s hash.
  • For parent‑aware enforcement (block execution only when launched by Cursor.exe), consider endpoint detection and response (EDR) solutions or custom security agents.

Individual developers

  • Open untrusted repositories only inside an isolated VM, Windows Sandbox, or another disposable environment until Cursor releases a fix.
  • Do not rely on file‑hash blocklists; the malicious binary can be rebuilt with a different hash.

Timeline of disclosure attempts

Date Action
15 Dec 2025 Vulnerability discovered and reported to security-reports@cursor.com
15 Dec 2025 Follow‑up request for receipt confirmation
13 Jan 2026 Public LinkedIn request for a security contact
15 Jan 2026 Cursor CISO replies – automation failure, manual invitation to private HackerOne bounty
15 Jan 2026 Report submitted via HackerOne
16 Jan 2026 Report closed as Informative and out of scope
16 Jan 2026 Mindgard challenges decision; report reopened after reproduction
20 Jan 2026 HackerOne confirms delivery to Cursor
16 Feb 2026 – 1 Apr 2026 Multiple update requests receive no response
1 Jun 2026 Mindgard notifies HackerOne of intent to disclose publicly
3 Jun 2026 HackerOne provides disclosure guidance
14 Jul 2026 Full disclosure blog post published

Community reaction on Hacker News

  • @wxw expressed disappointment at Cursor’s silence despite repeated outreach.
  • @jjcm argued that an attacker must already have placed a malicious .exe in the user’s filesystem, likening it to a compromised .bashrc—but the core issue remains that Cursor automatically runs the file.
  • @Illniyar noted that Windows’ default ACL prompts would block unsigned executables unless the user has disabled them, highlighting a potential mitigation.
  • @bragr pointed out that Windows searches the current working directory before PATH, making many tools vulnerable to the same pattern.
  • @dools warned that AI‑driven agents that pull from Git could amplify the risk, turning a single compromised repo into a supply‑chain attack vector.
  • @lemagedurage highlighted that Cursor ships with Workspace Trust disabled by default, meaning any repo‑level task can execute code without user consent.

Why Cursor has not patched the issue

The blog post and comments suggest several possible reasons, none confirmed by the vendor:

  1. Prioritization: Cursor may be focusing on feature development and its recent SpaceX acquisition, relegating security fixes.
  2. Bug‑bounty overload: The rapid growth of AI‑assisted development tools has increased report volume, potentially straining triage resources.
  3. Perceived low impact: Some commenters argue that an attacker must already have placed a malicious binary, which they view as a limited threat model.
  4. Windows‑specific behavior: The flaw exploits a long‑standing Windows PATH quirk (current directory precedence), which may be seen as a platform issue rather than a Cursor bug.

Regardless of the underlying cause, the lack of communication violates the expectations of coordinated disclosure and leaves millions of users exposed.

Broader implications for AI‑assisted development tools

  • Trust vs. safety: AI IDEs like Cursor request deep access to source code, terminals, and credentials. Trust should be earned through robust security practices, not assumed because the product is “productive.”
  • Disclosure pipelines under strain: As AI tooling proliferates, the volume of novel findings outpaces traditional bug‑bounty and coordinated‑disclosure processes.
  • Need for transparent security processes: Vendors must provide clear status updates when a report is received, reproduced, and prioritized. Silence erodes confidence and forces researchers toward full disclosure.

Recommendations for organizations using Cursor

  1. Implement the mitigations above (AppLocker, sandboxing) immediately.
  2. Audit existing repositories for unexpected git.exe files in the root.
  3. Monitor process creation on developer workstations for unexpected git.exe launches originating from Cursor.exe.
  4. Engage with Cursor’s security team (if they respond) to obtain a timeline for a fix or a temporary configuration flag that disables workspace‑root binary lookup.
  5. Consider alternative IDEs for high‑risk environments until the issue is resolved.

Conclusion

Cursor’s automatic execution of a git.exe found in a repository root constitutes a straightforward yet high‑impact remote code execution vulnerability. Despite being reported in December 2025 and reproduced by HackerOne, Cursor has not issued a patch or substantive response after seven months. Users must apply defensive mitigations now, and the broader AI‑tooling ecosystem should reassess how security disclosures are handled to prevent similar lapses in the future.

Key takeaway: Cursor’s design flaw lets any git.exe placed in a project’s root run silently, giving attackers a trivial path to execute malicious code on millions of Windows developer machines; the vendor’s silence underscores the need for immediate user‑level mitigations and a more accountable disclosure process.

Sources

Related