Cursor IDE Zero-Day RCE: 7 Months, 197 Releases, Zero Response — How a $60 Billion AI IDE Ignored a Trivial Bug
Mindgard published a full public disclosure on July 14, 2026, for an RCE (remote code execution) vulnerability reported to Cursor on December 15, 2025. After 7 months, 197 new releases, and repeated follow-ups, Cursor never responded.
My first reaction reading the disclosure wasn't "impressive exploit" — it was "how is this bug so basic?" Technically it's not complex at all: place a malicious git.exe in a repository's root directory, and Cursor on Windows will automatically execute it when loading the project. Zero clicks, zero prompts, zero warnings.
The Vulnerability
The attack chain is short:
1. When loading a project, Cursor scans multiple paths for the Git binary, and the workspace root is one of them;
2. If an attacker plants a git.exe in the repo root, Cursor invokes it as if it were the system Git;
3. Cursor triggers this binary repeatedly during normal IDE operations (commands like git rev-parse --show-toplevel), requiring no user interaction;
4. Mindgard's POC: rename Windows Calculator to git.exe, put it in the repo root, open Cursor — Calculator launches repeatedly.
Execution runs with the current developer user's privileges. What's at stake: API keys, .env files, SSH keys, local databases, and full access to the development machine.
Mindgard's disclosure timeline (from the original blog):
- 2025-12-15: Vulnerability discovered, submitted to Cursor via HackerOne;
- 2026-01-15: Cursor's CISO manually added the researcher to the bug bounty program, acknowledging an "automation failure";
- 2026-01-16: The report was first closed as "out-of-scope," then reopened after being challenged;
- 2026-02 to 2026-06: Multiple follow-ups, no replies;
- 2026-06-01: Mindgard publicly announced intent to disclose;
- 2026-07-14: Full disclosure. The vulnerability was still present in v3.2.16, tested April 30.
- Enterprise/managed Windows: use AppLocker or Windows App Control to deny execution of .exe files in workspace directories by path (e.g.,
%USERPROFILE%\source\repos*\filename.exe); do not use hash blocklists (attackers can change hashes at will); - Individual developers: only open untrusted repositories in isolated environments (Windows Sandbox, VMs, throwaway containers);
- Don't rely on hash blocking, since the attacker's binary changes every time.
- Will Cursor patch quickly? As of the July 14 disclosure, no official statement. Some on Hacker News speculate the more likely path is a quiet path-filtering fix at some point rather than public patch notes — publicly admitting "we left a trivial RCE unpatched for 7 months" is a PR disaster for a $60B-valued IDE.
- Will a CVE be assigned? None yet. If MITRE later assigns one, this becomes a "responsible disclosure failure" case study cited well into the 2030s.
- In-the-wild exploitation? Mindgard hasn't reported any, but numerous malicious git.exe POC repos already exist on GitHub; the exposure window for Windows Cursor users is roughly 24–72 hours from disclosure.
- Impact on Cursor's ARR? Short-term, minimal — migration costs for 7M monthly users are too high. But enterprise CISOs will likely put Cursor on a "security audit report required" list, which genuinely hurts sales cycles.
- Do other AI IDEs have the same bug? WindSurf, Cline, Roo Code, Continue, and Zed AI have seen no similar disclosures, but search-path logic is nearly a universal pattern in IDEs. This disclosure amounts to a free penetration test for the entire industry.
No CVE was assigned. Because Cursor never formally accepted the report, the CVE process was never initiated.
The most uncomfortable line in the disclosure is Mindgard's: "Coordinated disclosure only works when both sides are willing to coordinate." They chose users over silence.
Deeper Analysis
I care less about the technique and more about why Cursor, the company, behaved this way.
First, Cursor's scale, per the disclosure's own numbers: 7M+ monthly active users, 1M+ daily active users, 1M+ paying users, 50,000+ enterprise customers, and a $60 billion valuation. It's the number two in AI coding tools behind GitHub Copilot.
Now the bug itself: it's the most vanilla search-path logic in any dev environment — a single unit test should have caught it in theory. But it survived 197 releases, and that points to only one explanation: Cursor's security process was broken during this period. The CISO manually adding the researcher (the report bypassed normal channels), the report auto-flagged as out-of-scope (triage failure), and no replies to follow-ups (no SLA) — for an IDE used daily by 7 million developers, all three failing simultaneously is more serious than the bug itself.
Then look at DuneSlide's finding. Another high-severity Cursor vulnerability disclosed on April 2, 2026 (CVE-2026-50548/50549, CVSS 9.8, zero-click sandbox escape via MCP servers or search results) was fixed in Cursor 3.0. So the security team isn't incapable, nor does it ignore all bugs — it responds selectively. Mindgard's report was likely classified as out-of-scope because it's "classic IDE security," not AI/Agent related, and was deprioritized. The irony: this "classic IDE security" is exactly the kind of basic pitfall developers hit every day.
Finally, the disclosure strategy. Mindgard didn't follow a standard 90-day cycle — from report to disclosure took a full 7 months, far exceeding industry norms. The disclosure holds nothing back: attack path, POC, user mitigations, and what the vendor should have done. This is textbook responsible disclosure; the target just never showed up.
Why It Matters
First, this is the first time an AI coding tool security issue has appeared as a triple whammy: zero-day + public disclosure + zero vendor response. The July 13 Grok CLI incident (silent code and key exfiltration) was a privacy failure baked into the tool; the Cursor zero-day is a hole in the tool's own code-execution foundation. Two different attack surfaces: the former threatens your data, the latter your machine. AI coding tools have a far larger attack surface than traditional IDEs, but vendors haven't raised their security posture to match.
Second, it's a warning to every AI coding vendor: security in the AI era isn't LLM alignment — it's the end-to-end trust chain. A week spent checking whether your IDE executes binaries from the repo is worth more than a year spent preventing the model from outputting harmful content. That's Cursor's lesson to the industry.
Third, the mitigations for ordinary developers are clear but costly — Mindgard listed them directly:
For individuals, the practical cost is high — reviewing GitHub PRs, reading open-source code, or interviewing candidates would all require running Cursor inside an isolated environment.