Cursor's 7-Month Unfixed 0day — When AI Coding Tools Become the Attack Surface

Here's the vulnerability in one sentence: If you open a repository in Cursor on Windows, and that repository contains a malicious git.exe in its root, Cursor executes it automatically. No prompts. No warnings. No clicks.

Here's the part that should alarm you more: Aaron Portnoy at Mindgard reported this on December 15, 2025. As of today, July 14, 2026 — over 197 versions later — it's still present in the latest shipped build.

This is full-disclosure-as-nuclear-option: 7 months of silence, a HackerOne report closed as "Informative" then reopened, a CISO who acknowledged the issue then vanished, and zero evidence of a fix, a patch plan, or a user notification.

The Vulnerability Is Almost Embarrassingly Simple

The bug lives in Cursor's path resolution logic for finding Git binaries. Cursor searches multiple locations for git.exe — and one of those locations is the workspace root. If a planted binary named git.exe exists there, Cursor picks it up and starts calling it. Repeatedly.

Mindgard's proof of concept: rename calc.exe to git.exe, drop it in a repo, open the repo in Cursor. Multiple Calculator windows appear automatically. A procmon trace confirms the chain:

Cursor.exe → Process Create → git rev-parse --show-toplevel

The same logic would execute a remote access trojan, ransomware, or credential stealer. No trickery required.

"If you take a remote access Trojan, a ransomware binary, or whatever you want to execute and just call it git.exe, it runs unrestricted on the developer's machine as soon as they open the repo." — Aaron Portnoy, CPO Mindgard

The Disclosure Timeline Is Worse Than the Bug

Let me walk you through what happened after Portnoy found this, because it's a case study in how broken coordinated disclosure can get.

The pattern is unmistakable: acknowledge, promise, ghost. The report did eventually reach the right people. But once it landed, the silence was total. No progress updates. No fix estimate. No notification to affected users.

Portnoy puts it bluntly:

"Even without their source code, I could fix this vulnerability in about five minutes by reverse engineering the one line change they need to make. It's baffling to me that we reported this in December and they've yet to fix it."

This Is the Third Striking Cursor Vulnerability in 6 Months

What makes this story particularly uncomfortable is that it's not an isolated incident.

• April 2026 — CVE-2026-26268 (CVSS 9.9): A sandbox escape via writing .git configuration files. Malicious Git hooks triggered automatically when Cursor's AI agent ran git checkout. Patched in Cursor 2.5.
• June 2026 — CVE-2026-50548 / CVE-2026-50549 (CVSS 9.8, "DuneSlide"): Two sandbox bypass flaws that let prompt injection escape the command execution sandbox entirely, enabling OS-level RCE without user interaction.
• July 2026 — This 0day (itself unfixed): No sandbox escape required. The IDE executes arbitrary binaries from the workspace just by opening a repo.

The DuneSlide bugs were reported by Cato AI Labs in February 2026 — and their initial report was also rejected before being escalated. That's a pattern, not a coincidence.

Cursor is valued at $60 billion, has over 7 million active users, 1 million daily active users, and 50,000+ enterprise customers. These aren't startup growing pains. This is a systemic security posture problem.

What the Fix Looks Like

The fix is trivial in concept: don't include the workspace root in your Git binary search path. Strip it from path resolution, or at minimum require a prompt before executing a binary from an untrusted workspace directory.

For Windows enterprise environments, Mindgard recommends AppLocker or Windows App Control with path-based deny rules scoped to workspace roots — e.g., blocking %USERPROFILE%\source\repos\*\git.exe. Hash-based rules won't work because the attacker controls the binary. And parent-process-aware blocking (only blocking execution if the parent is Cursor) requires proper EDR tooling — Windows doesn't natively support it.

For individual developers: open untrusted repos in a VM or Windows Sandbox. Do not rely on file hash blocklists for this.

The Bigger Picture

This isn't really about git.exe. It's about the fundamental shift in trust that AI coding tools demand — and how poorly the industry has responded.

An AI coding IDE isn't just an editor. It reads your entire codebase. It sends code to remote servers. It installs packages. It runs pre-commit hooks. It executes shell commands on your behalf. It has credentials, secrets, and API keys in its session. The trust surface is enormous.

Every one of these capabilities can be weaponized. We've seen:

• Cursor rules files used to inject malicious behavior into AI assistants
• Mozilla 0DIN demonstrating a reverse shell through Claude Code using zero malicious code
• Supply chain attacks via poisoned cursorrules files shared on code marketplaces

The pattern is clear: AI coding tools are the ideal supply chain malware vector. They have permissive execution models, broad system access, and a user base that implicitly trusts them because they're useful.

Portnoy puts it best:

"Trust should not be granted because something is useful. It should be earned through behavior."

What Developers Should Do Right Now

If you use Cursor on Windows:

1. Don't open untrusted repos — treat every repo you clone that you didn't personally write as potentially hostile.
2. Use a sandbox — Windows Sandbox or a VM for any code you're evaluating that comes from an untrusted source.
3. Audit your Git path — check if Cursor is picking up a git.exe from somewhere unexpected.
4. Watch for a fix — Cursor released a statement on July 13 saying "we are addressing this." Watch for a patch and apply it immediately.

More broadly, start treating AI coding tools as part of your threat surface. They offer enormous leverage to attackers. The industry is going to learn this lesson the hard way — and the learning is only accelerating.

Full disclosure: The original vulnerability was discovered and reported by Aaron Portnoy, Head of Research & Innovation at Mindgard. The full disclosure post is published on Mindgard's blog. Additional coverage from Dark Reading.

This story is breaking as of July 14, 2026. We'll update this piece as Cursor responds and if a patch is issued.