Security researchers at Mindgard have disclosed a critical zero-day vulnerability in Cursor, the AI-powered code editor used by over 7 million developers worldwide. The flaw allows arbitrary code execution on Windows simply by opening a repository containing a malicious git.exe binary in its root directory. No clicks, no prompts, no warnings — just open the project and the code runs.

The vulnerability has existed since at least December 2025. Mindgard reported it to Cursor's security team the same day. Seven months and 197+ Cursor releases later, the issue remains unpatched. Full disclosure was published July 14, 2026.

Vulnerability Details (CVE Pending)

Impact: Arbitrary code execution as the current user on Windows
Attack Vector: Local — attacker must plant a malicious git.exe in a repository root
User Interaction: None required — executes automatically on project load
Affected Versions: All tested versions through v3.2.16 (April 2026)
Platform: Windows only (macOS and Linux not affected)

The root cause is straightforward. When Cursor loads a project, it searches for Git binaries across multiple locations to power its version control features. One of those search paths is the workspace root itself. If a file named git.exe exists there, Cursor executes it with arguments like git rev-parse --show-toplevel — no validation, no signature check, no user confirmation.

Mindgard's proof-of-concept demonstrates the issue harmlessly: rename Windows Calculator (calc.exe) to git.exe, place it in a repository root, open the repo in Cursor. Calculator launches. Leave the project open and Calculator relaunches repeatedly as Cursor re-runs its Git discovery logic.

In a real attack, calc.exe becomes whatever payload the adversary chooses — a reverse shell, credential harvester, ransomware dropper, or supply-chain implant targeting the developer's environment and any systems they access.

Impact Assessment

Cursor reports 7 million+ active users, 1 million+ daily active users, 1 million+ paying subscribers, and adoption across 50,000+ companies. The developer machine is a high-value target: it holds source code, cloud credentials, SSH keys, API tokens, and often serves as a jumping-off point to production infrastructure.

A compromised developer workstation enables:

• Source code theft — exfiltration of proprietary code and intellectual property
• Credential harvesting — AWS keys, GitHub tokens, database passwords, Kubernetes configs
• Supply chain poisoning — malicious commits signed with the developer's GPG key
• Lateral movement — VPN access, bastion hosts, CI/CD systems reachable from the dev machine
• Persistent access — modified shell profiles, SSH authorized_keys, scheduled tasks

The vulnerability is particularly dangerous in collaborative workflows. A malicious git.exe committed to a shared repository (or injected via a compromised dependency) executes on every team member's machine when they open the project. CI/CD systems that clone and inspect repositories in Windows environments are also at risk.

Affected Systems

Any Windows machine running Cursor with a project containing a git.exe at the repository root is vulnerable. This includes:

• Individual developers cloning untrusted repositories
• Teams pulling from shared Git hosting (GitHub, GitLab, Bitbucket, Azure DevOps)
• Enterprise environments with managed Cursor deployments
• Build agents and CI runners on Windows that use Cursor for code analysis

The fix is not deployed as of July 14, 2026. All current versions remain vulnerable.

Mitigation & Patching

No official patch exists. Until Cursor releases a fix, apply these mitigations:

Enterprise / Managed Windows (AppLocker / Windows App Control)

Create a path-based deny rule blocking execution of git.exe from developer workspace directories:

Prefer path-based rules over hash-based rules — attacker-supplied binaries vary by hash. Note that Windows lacks a native parent-process-aware rule (block git.exe only when launched by Cursor.exe); endpoint detection and response (EDR) tools can enforce this more precisely.

Consumer / Unmanaged Systems

• Open untrusted repositories only in isolated environments: Windows Sandbox, a dedicated VM, or a disposable container.
• Do not rely on file hash blocklists — the attacker controls the binary content.
• Audit repositories before opening: Check for unexpected executables at the repo root (ls -la *.exe / dir *.exe).
• Consider alternative editors for reviewing untrusted code until a patch lands.

Repository Hygiene (Defense in Depth)

• Configure .gitignore to exclude *.exe at the root (though this doesn't prevent an already-committed binary).
• Use Git LFS for large binaries; treat unexpected .exe files in repos as suspicious.
• Scan repositories with git ls-files '*.exe' during code review.

Detection

Monitor for suspicious process creation where Cursor.exe spawns git.exe from a non-standard location:

On endpoints with Sysmon (Event ID 1), alert on Image: git.exe with ParentImage: Cursor.exe where the git.exe path is outside known Git installation directories.

Frequently Asked Questions

Q: Does this affect macOS or Linux?
A: No. The vulnerable code path searches for git.exe specifically, a Windows executable name. On Unix-like systems, Cursor looks for git without the .exe extension, and the workspace root is not in the search path.

Q: Is there a CVE assigned?
A: Not yet. Mindgard's disclosure (July 14, 2026) is the first public detail. A CVE request has been filed.

Q: Can this be exploited remotely?
A: Not directly. The attacker needs a developer to open a malicious repository. However, supply-chain scenarios (compromised upstream dependency, malicious PR, typosquatted package) make remote delivery practical.

Q: Why did Mindgard go full disclosure after 7 months?
A: Coordinated disclosure requires coordination. Mindgard reported the issue December 15, 2025, followed up multiple times, engaged Cursor's CISO via LinkedIn, entered the HackerOne private program, had the report reopened after initial "Informative/out of scope" closure, and received zero meaningful updates for months. With 197+ Cursor releases shipped and no fix, they concluded silence no longer protects users — it protects the vendor.

Q: What should I do right now if I use Cursor on Windows?
A: Stop opening untrusted repositories in Cursor on Windows. Use Windows Sandbox or a VM for code review. Apply AppLocker rules if you manage endpoints. Watch for a Cursor security advisory and update immediately when released.

Q: Are other AI editors affected?
A: This specific git.exe search path issue is unique to Cursor's implementation. However, the class of vulnerability — IDEs executing workspace content without validation — warrants scrutiny across VS Code extensions, GitHub Copilot, Windsurf, and similar tools.

Key Takeaways

1. A critical RCE in the most popular AI coding tool has been unpatched for 7 months. Cursor's 7-million-user base has been exposed since December 2025.

2. The vulnerability is trivial to exploit. Plant a git.exe in a repo root; Cursor runs it automatically on project load. No user interaction, no prompts.

3. Vendor non-response forced full disclosure. After repeated private reports, HackerOne escalation, and direct CISO outreach yielded no fix, Mindgard published to protect users.

4. Developer machines are high-value targets. Compromise yields source code, credentials, and lateral access to production. This vulnerability turns a git clone into an initial access vector.

5. Mitigation is possible today. AppLocker path rules, Windows Sandbox, and repository auditing reduce risk until an official patch arrives.

6. The industry must demand better from AI tool vendors. Rapid feature velocity cannot excuse months of silence on critical security flaws. Trust requires accountability.

Conclusion

The Cursor 0day is a wake-up call. As AI coding assistants gain deep access to our terminals, repositories, and cloud environments, their attack surface expands dramatically. A tool that executes workspace content without verification breaks the fundamental trust model of software development: that opening a project is a read-only, safe operation.

Cursor's users — individual developers, startups, and enterprises alike — deserve a timely patch and transparent communication. Until then, treat every untrusted repository on Windows as potentially hostile, and isolate your review environments accordingly.

---

Sources:

• Mindgard Blog: Cursor 0day: When Full Disclosure Becomes the Only Protection Left (July 14, 2026)
• HackerOne report timeline (via Mindgard disclosure)
• Cursor security.txt: https://cursor.com/.well-known/security.txt
• CSA Singapore advisory process reference