A developer opens a repository in Cursor on Windows. If that repo contains a file named git.exe in the root, Cursor executes it automatically. No clicks. No warnings. No prompts. Just code execution — under the current user's privileges.
Mindgard found this on December 15, 2025. They reported it the same day. Today is July 2026 — 197+ Cursor versions later — and it's still there.
"The vulnerability is almost boring in its simplicity, and that may be the most concerning part." — Mindgard
What actually happened
The bug is a path resolution problem. When loading a project, Cursor searches multiple locations for Git binaries — one of which is the workspace root itself. If an attacker plants a malicious git.exe there, Cursor picks it up and runs it. Repeatedly. On a cadence, while the project is open.
Mindgard's proof-of-concept: Windows Calculator, renamed git.exe, dropped in a repo root. Open the project in Cursor and watch Calculator instances multiply on their own.
In a real attack, Calculator is replaced with anything the attacker wants to run.
The disclosure timeline is the worse story:
- Dec 15: Reported to Cursor's security email (as listed in their
security.txt) - Jan 15: Cursor's CISO finally responds — an automation failure blocked HackerOne invite
- Jan 16: Report submitted to HackerOne, initially closed as "Informative and out of scope"
- Jan 16: Mindgard challenges, issue reproduced, report reopened
- Jan 20: HackerOne confirms delivery to Cursor
After that: silence. Follow-ups unanswered. Escalation to leadership: no response. Months of nothing while Cursor shipped features, raised money at a reported $60B valuation, and announced a SpaceX acquisition.
The disclosure dilemma
Coordinated disclosure works when both parties want it to. After seven months without a status update — let alone a fix — Mindgard faced the choice every researcher eventually faces: stay quiet and let users assume they're safe, or go public so organisations can protect themselves.
They went public.
Full disclosure isn't the first choice; it's what happens when every other path closes. Users of a platform trusted by 50,000+ companies and 7 million developers — handling source code, credentials, secrets, and autonomous workflows — deserve to know when they're exposed.
What to do right now
Enterprise / managed Windows: Use AppLocker or Windows App Control to deny execution of the affected executable name from workspace directories. Scope deny rules to repo roots (e.g. %USERPROFILE%\source\repos\*\filename.exe). Hash-based rules won't cut it — attacker-supplied binaries vary by hash.
Consumer / personal machines: Until this is patched, open untrusted repositories only inside a VM, Windows Sandbox, or other isolated environment. Don't assume a file hash blocklist covers this.
Everyone: This is a supply chain scenario. Any contributor to a shared repo could plant this. Treat unfamiliar repos the way you'd treat unfamiliar package.json scripts.
The bigger question
Cursor isn't the only AI dev tool asking for deep access to your codebase, terminal, and secrets. The whole category is built on trust — trust that the vendor is shipping secure software and taking security reports seriously.
When a straightforward, high-impact, trivially reproducible bug sits unpatched for seven months at a company valued at tens of billions, that trust has to be re-evaluated. Not just for Cursor — for every AI dev tool you're handing repo access to.
Trust is earned through behavior. This is behavior.
Source: Mindgard full disclosure — July 15, 2026
✏️ Drafted with KewBot (AI), edited and approved by Drew.
SOCIAL SHARE CARD GENERATOR