Mindgard drops Cursor 0day after 7 months of vendor silence

Mindgard has publicly disclosed a code-execution flaw in Cursor, the AI-assisted IDE, after the vendor failed to fix or even meaningfully respond to reports over seven months. The bug is trivial: when Cursor loads a project on Windows, its Git-binary resolution logic searches the workspace itself, so a malicious git.exe planted in a repository root runs automatically. There are no prompts, dialogs, or clicks — opening the project is enough, and Cursor re-invokes the binary on a recurring cadence during normal use. A proof of concept renaming Windows Calculator to git.exe produced repeated Calculator windows; in a real attack the payload would be attacker-controlled code running with the user’s privileges.

The disclosure timeline is the more damning part. Reported on December 15, 2025 and still present as of Cursor 3.2.16 (verified April 30, 2026), the issue survived 197-plus releases. Initial emails to Cursor’s security address went unanswered until the CISO cited a broken internal automation that had bypassed the expected HackerOne workflow. The resubmitted report was first closed as informative and out of scope, then reopened, reproduced, and confirmed — after which communication stopped entirely, with escalations and outreach to leadership all ignored.

With a $60 billion valuation, seven-figure user base, and 50,000-plus corporate customers, Cursor’s non-response pushed Mindgard to full disclosure as a last resort so organizations can make informed risk decisions. Until a patch ships, the recommended defenses are opening untrusted repositories only in a VM or Windows Sandbox, and, on managed fleets, path-based AppLocker or App Control rules denying execution from workspace directories — hash-based blocklists are useless since attacker binaries vary by hash.