Cursor 0day: 7-Month-Old Code Execution Bug Exposes Every AI Coder's Blind Spot

Here's how bad it is.

You open a repository in Cursor on Windows. If that repository happens to contain a file called `git.exe` in its root, Cursor executes it. Silently. No dialog box. No "are you sure?" No indication anything happened at all. It runs attacker-controlled code with your privileges, and it does it repeatedly on a cadence while the project stays open.

This is not a sophisticated exploit chain. Mindgard's proof of concept renamed Windows Calculator to `git.exe` and dropped it in a repo. Cursor launched it again and again — the screenshot in their disclosure shows multiple Calculator windows stacking up, none of them triggered by the researcher.

The vulnerability was discovered on December 15, 2025. It was reported the same day. As of July 14, 2026 — seven months and over 197 new versions later — it remains unpatched. Mindgard went public this week because coordinated disclosure ran out of road.

Seven months of silence from a $60 billion company

Cursor has seven million active users. A million of them pay. Fifty thousand companies have it deployed. The company is reportedly valued at $60 billion and in the process of being acquired by SpaceX. It ships features at a pace that makes most software companies look stationary.

And for seven months, it couldn't find the time to stop auto-executing random binaries from untrusted repositories.

What happened behind the scenes is almost as damning as the bug itself. Mindgard sent the initial report to Cursor's security email, per the company's published `security.txt`. No response. Follow-ups went unanswered. Public outreach eventually flagged the failure — Cursor's CISO admitted an "internal automation failure" had prevented the HackerOne workflow from triggering. The researchers were invited into the private bug bounty programme. They resubmitted.

HackerOne initially closed the report as "Informative" and out of scope. After Mindgard challenged that call, the platform reopened it, reproduced the issue, and confirmed it had been delivered to Cursor.

Then: nothing. Requests for updates went dark. Escalation through HackerOne produced nothing. Direct outreach to leadership produced nothing. Month after month, Cursor shipped new versions — more than 70 in the period tracked — while the vulnerability sat there, reproducible in under a minute.

This is not a hard bug to fix. Cursor attempts to locate Git binaries across several locations when loading a project. One of those locations is the workspace itself. You would fix this by... not doing that. Exclude the workspace root from the Git binary search path. Done.

The fact that the fix is trivial makes the silence worse. It signals either catastrophic process failure or active indifference.

What this means for anyone using AI coding tools

I've been writing about vibe coding security risks for months now. The 5,000-plus exposed apps from vibe-coded projects. The Claude watermarking scandal. The trust gap where 84% of developers use AI-generated code but only 29% trust it.

The Cursor 0day is different. It's not about whether AI writes secure code. It's about whether the tool itself is a vector.

If your team uses Cursor — and statistically, someone on your team probably does — every repository they open is a potential execution path for malicious code. Not code the AI wrote. Code an attacker planted, knowing Cursor will run it without asking.

Think about the supply chain implications for a moment. A developer clones a repo. Maybe it's a dependency. Maybe it's a fork of a popular library. Maybe it's an internal project where someone's credentials got compromised six months ago and a `git.exe` got slipped into the root. Cursor opens it and silently executes the payload. No amount of code review catches this because it happens before you read a single line.

This is the kind of vulnerability that keeps security teams awake. It's simple, reliable, and requires zero social engineering beyond getting someone to open a project — which is what developers do all day.

Why no-code platforms don't have this problem

There's a structural difference between AI coding tools and no-code platforms that this incident throws into sharp relief.

Cursor, Copilot, Windsurf, Bolt — these tools run on your machine. They execute code. They interact with your file system, your shell, your environment variables. That's their value proposition: they meet developers where they work. The downside is that they inherit every security property of that environment, including the ability to silently execute arbitrary binaries.

No-code platforms — Bubble, Webflow, Stacker, the whole category — operate inside a managed runtime. There is no local execution chain to exploit because there's no local execution. The platform owns the sandbox, the deployment pipeline, the authentication layer. You can't drop a malicious binary into a Bubble app and have it auto-execute on someone's machine because Bubble doesn't execute binaries on anyone's machine.

This isn't to say no-code platforms are immune to security issues. They have their own attack surface. But it's a different class of surface. The Cursor vulnerability is local arbitrary code execution via automatic path resolution. That entire category of bug does not exist on platforms that never execute local binaries.

For businesses trying to figure out their AI tooling strategy, this distinction matters. If your security model assumes the tools themselves are trustworthy, the Cursor 0day is evidence that assumption needs revisiting. The tool that "just works" might also "just execute" something you didn't authorise.

The disclosure process itself is broken

Mindgard did everything right. They reported promptly, followed up repeatedly, escalated through channels, went to HackerOne, challenged the initial rejection, waited months. They only went public after exhausting every option.

The disclosure ends with a question that deserves an answer: what exactly is the security process for? If a trillion-dollar-adjacent company with a dedicated CISO and a HackerOne programme can ignore a trivially reproducible arbitrary code execution bug for seven months, the process isn't functioning. It's performing.

Mindgard calls full disclosure "the nuclear option" and they're right. But as they point out, it exists for exactly this scenario: when the vendor stops communicating, users shouldn't be left in the dark. Every Cursor user on Windows is now on notice, which is the only protection available since no patch exists.

What to do right now

If you're on a managed Windows system, use AppLocker or Windows App Control to deny execution of `git.exe` from workspace directories. Path-based deny rules are the play, not hash-based ones — attackers can trivially vary the binary.

If you're on a consumer system, don't open untrusted repositories outside an isolated VM or Windows Sandbox. That's obviously impractical as a permanent policy. It's a stopgap until Cursor ships a fix, which, given the public pressure now, will hopefully happen quickly.

For teams evaluating AI coding tools: ask vendors what happens when a security researcher finds a bug in their product. Ask about disclosure timelines, patching SLAs, and who specifically owns the security response process. If the answer is vague, treat the tool accordingly.

The uncomfortable truth of the Cursor 0day isn't that the bug exists. Bugs exist in everything. It's that the company behind a tool used by seven million developers apparently couldn't be bothered to fix it. That's not a technical failure. It's an institutional one. And institutional failures don't get patched in the next release.