Mindgard just published a full disclosure on a Cursor 0-day. It is unpatched, seven months after they reported it.
The bug is almost embarrassingly simple. Put a file named git.exe in a repo’s root. Open that repo in Cursor. It runs. On open. No prompt, no approval, no indication that anything executed at all.
Here is how it works, why it survived 197 releases, why the agent guardrails everyone is buying would not have caught it either, and what you can actually do today.
tl;dr
- Cursor searches the workspace root for a
gitbinary when it opens a project. Plant one there and its path-resolution logic runs it, with your privileges, on open. - Windows, tested through 3.2.16 (Apr 30, 2026). Still unpatched at disclosure.
- The proof of concept was Windows Calculator renamed to
git.exe. Task Manager counted 15 of them. - Reported Dec 15, 2025. Over 197 releases shipped without a fix. Mindgard went public on Jul 14, 2026.
- It fires inside the editor’s own process, which is exactly why hooks and agent sandboxes never see it. That is a property of the whole guardrail category, not one product.
- Until it is patched: open untrusted repos in a VM or Windows Sandbox, and add AppLocker/WDAC deny rules on executables in your repo directories.
The bug
Every editor needs git. The problem is where Cursor looks for it. Its search path includes the workspace root itself. So the lookup goes “is there a git here? yes? run it.”
An attacker drops git.exe at the top of a repo. You clone it, or open a folder someone shared, or an agent pulls it down for you. Cursor opens, does its git discovery, finds that git.exe, and executes it with your privileges as part of normal startup. Mindgard’s words, worth quoting exactly:
Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is about to run.
And it repeats on a cadence while you work, because Cursor keeps calling git.
The proof of concept
They renamed Windows Calculator to git.exe and opened the repo. Calculators started popping. Task Manager counted 15 of them.
Sysinternals confirmed where they came from: git rev-parse --show-toplevel, running straight out of Cursor.exe.
Calculator is the polite choice. Swap it for anything else and you see the actual problem: this is arbitrary code execution triggered by opening a folder.
Seven months and 197 releases
The timeline is its own story:
- Dec 15, 2025 reported to security-reports@cursor.com
- Jan 15, 2026 Cursor’s CISO acknowledges an automation failure, invites them to HackerOne
- Jan 16 report closed as “Informative and out of scope”, reopened after a challenge
- Feb to Apr update requests go unanswered
- Jun 1 Mindgard announces intent to disclose
- Jul 14 full disclosure
Over 197 new versions shipped in that window. No fix, no advisory, no notice to users. Their conclusion is hard to argue with:
Coordinated disclosure only works when there is coordination.
For scale: Cursor reports 7M+ users across 50,000+ companies.
Why your agent guardrail misses this
This is the part worth internalising, because it outlives this bug.
Any tool guarding your coding agent watches at one of three altitudes:
Layer 1, the tool call. The agent decides to run rm -rf ~/.ssh, or write a file, or call an MCP. A hook fires before it runs and says allow, deny, or ask. It sees what the agent decided to do.
Layer 2, the process tree. You launch the agent inside an OS sandbox, so everything the agent spawns inherits the restrictions. Landlock on Linux, Seatbelt on macOS. It sees what the agent spawned.
Layer 3, the whole system. Kernel-level enforcement on any process, whether or not you launched it. eBPF LSM on Linux, a system extension on macOS. It sees everything.
Now put this bug on that map. The git.exe is spawned by Cursor.exe, during path resolution, when the folder opens. Not by the agent. So:
- Layer 1 is blind. The agent decided nothing. There is no tool call, no hook event, nothing to allow or deny.
- Layer 2 is blind. The sandbox constrains processes descended from the agent you launched. This one is a child of the editor. It was never inside the jail.
- Layer 3 catches it. System-wide enforcement does not care who spawned what.
Almost every product in this space lives at layer 1, some at layer 2. That is not laziness. Those layers are cheap, portable, and catch the overwhelming majority of what actually goes wrong. But it means the honest answer to “would my guardrail have stopped this?” is almost certainly no, whoever you buy from.
The question this bug really asks: what runs on your machine that isn’t your agent? Your editor. Your extensions. Your language server. Your build. Your package manager’s post-install hooks. All of that sits outside layers 1 and 2.
What to do today
Cursor is unpatched, so this part is not about tools you can buy. Mindgard’s guidance, and it is correct:
Open untrusted repositories only in isolated VMs or Windows Sandbox environments.
On enterprise Windows, AppLocker or WDAC path-based deny rules on executables under your repo directories stop this specific shape of attack.
On any OS, the durable habit is the boring one: treat a repo you didn’t write like a pen drive from a stranger. The act of opening it can be enough. That was true before this bug and it will be true after they patch it.
Where agentjail sits
Layers 1 and 2 are shipped. Hooks over tool calls, and an OS sandbox built on Landlock and Seatbelt that confines the agent and everything it spawns. That is what contains the problem this bug belongs to: untrusted repo code that runs through your agent can’t read ~/.ssh or ~/.aws, and can’t phone home past a default-deny proxy.
Layer 3 is on the roadmap as eBPF LSM / system extension: system-wide kernel enforcement for any process, not just hooked agents. That is the tier that sees an editor execute a planted binary. It is planned, not shipped, and I’m not going to pretend otherwise while the news cycle is hot. Worth noting too: this CVE is Windows, and the shield is Linux and macOS today.
Takeaways
- Untrusted repo means untrusted code execution. Not “might contain a bad script you run.” Opening it can be enough.
- Know your tool’s altitude. Layer 1 sees decisions. Layer 2 sees descendants. Layer 3 sees everything. Ask which one you’re actually buying.
- A vendor who tells you what they don’t cover is worth more than one who claims everything. If a guardrail company writes about this bug and implies they’d have stopped it, check which layer they’re at.
- Containment beats enumeration. You will never patch every exec-trust bug in every editor. You can make sure that when one fires, the code lands somewhere with no keys and no exit.
The bug is simple. Knowing exactly where your walls end is the whole game.
Thanks for reading :)
Credit where it’s due: the disclosure, the proof of concept, and seven months of chasing Cursor for a fix are all Mindgard’s work. I just drew the map around it.
If you want to see these layers doing something useful, I caught a coding agent shipping .env secrets on the wire and then blocked it in the previous post.
Aseem