Cursor IDE's Unpatched 0-Day: The git.exe Exploit Explained

If you use Cursor, here's the short version: opening the wrong repository on Windows can hand an attacker code execution on your machine, no click, no prompt, no warning. The bug has been sitting there since December 2025. As of this week, it's still unfixed.

Security firm Mindgard went public with the details on July 14, 2026, after seven months of trying to get Cursor to respond. If you're a developer who clones repos for a living, which is most of us, this is worth five minutes of your attention.

What's actually broken

Cursor is an AI-powered code editor, the kind that clones repos, runs Git commands on your behalf, and increasingly acts on its own instead of waiting for you to type every command. When you open a project, Cursor needs to find a Git binary to talk to, and it looks in a few places to find one. One of those places is the project folder itself.

That's the entire bug. If someone drops a file named git.exe at the root of a repository and you open that repository in Cursor on Windows, Cursor runs it. Immediately. Repeatedly, for as long as the project stays open. With your user privileges, meaning your SSH keys, your source code, your cloud tokens, and anything else you can touch.

Mindgard proved it with the safest possible demo: they renamed Windows Calculator to git.exe, dropped it in a repo, and opened that repo in Cursor. Calculator windows started popping up on their own. Swap that harmless .exe for a credential stealer or a ransomware loader, and you get the picture.

There's no social engineering step here. No phishing email, no "click to enable macros," no prompt injection tricking an AI agent into misbehaving. You just open a folder. Cloning a repository is precisely how binaries land on your disk in the first place, and developers do that all day, whether it's reviewing a pull request, checking out a candidate's take-home assignment, or pulling down a random GitHub project to see how someone solved a problem.

Why this took seven months to become public

Mindgard reported the flaw to Cursor on December 15, 2025. What followed is a fairly rough timeline for a company valued at $60 billion with more than 7 million users:

Mindgard's own framing of the decision to go public sums it up: "Coordinated disclosure only works when there is coordination." That's a fair read of a seven-month gap between a fully reproducible bug report and any visible sign it mattered.

To be clear about scope: this is specifically a Windows issue, tied to how Cursor resolves Git binaries on that OS. If you're on macOS or Linux, this particular flaw doesn't apply to you, though it's worth watching whether similar path-resolution issues turn up elsewhere.

This isn't Cursor's first rodeo this year

Worth knowing the context, because this is now a pattern rather than a one-off. Two other Cursor vulnerabilities surfaced earlier in 2026, both already patched:

• CVE-2026-26268, disclosed by security firm Novee in February, let a malicious Git hook fire automatically when Cursor's agent ran routine Git operations inside a booby-trapped repo. Fixed in Cursor 2.5.

• DuneSlide (CVE-2026-50548 and CVE-2026-50549), found by Cato Networks, let a zero-click prompt injection escape Cursor's sandbox entirely and run commands on the host OS. Fixed in Cursor 3.0, released April 2, 2026.

Both of those got patched within a reasonable window. This third one, the git.exe workspace lookup, hasn't. And unlike the other two, it doesn't even need an AI agent to misbehave or a prompt injection to succeed. It's a plain old path-resolution mistake that happens to sit inside a tool that 50,000+ companies now trust with their source code.

Cato Networks separately noted this class of bug isn't unique to Cursor. Several AI coding tools resolve helper executables using a search order that checks the working directory before trusted system paths, which is exactly the kind of thing that turns "open a folder" into "run untrusted code."

Why this matters more now than it would have three years ago

A regular code editor is passive. It opens files, and it runs whatever you explicitly tell it to run. An AI coding agent is a different animal: it interprets what you're trying to do and decides, on its own, which commands to execute to get there. That's the entire selling point of tools like Cursor, and it's also exactly why a bug like this is scarier than it would have been in a traditional IDE.

Your development machine isn't some throwaway sandbox. It's where your credentials live, where your .env files sit, where your SSH keys are cached, where you're logged into Azure, AWS, GitHub, your CI/CD pipelines, everything. A silent RCE tied to something as mundane as opening a repo turns every untrusted clone, every candidate's take-home project, every random GitHub link into a potential foothold on a machine that has access to production systems.

If you're running Hermes, n8n workflows, or anything else on a VPS that your dev machine has SSH keys or API tokens for, this is precisely the kind of bug that turns "I just wanted to peek at this repo" into a much worse afternoon.

How to protect yourself right now

There's no official patch as of this writing, so the mitigations are all about limiting what an untrusted repo can touch.

If you're an individual developer on Windows:

1. Stop opening unfamiliar repositories directly in Cursor on your main machine. Treat any repo you didn't write yourself as executable content, because that's what it is.

2. Use Windows Sandbox or a disposable VM for anything you haven't vetted. Clone it there first, look around, then decide whether it's safe to open on your real machine.

3. Don't rely on file-hash blocklists. An attacker can rename any binary to git.exe and the hash changes every time, so hash-based rules won't catch a new variant.

4. Check whether your machine even runs Git for Windows from a location Cursor might shadow. If you're unsure, this is a good moment to double check your PATH configuration.

If you're managing Windows endpoints for a team:

1. Set up AppLocker or Windows App Control path-deny rules scoped to developer workspace directories, something like %USERPROFILE%\source\repos\*\git.exe. Path-based rules matter here specifically because hash-based ones don't hold up.

2. If you have EDR tooling, add rules to flag or block unexpected child processes spawned by Cursor.exe, particularly anything invoked via a git rev-parse or similar call pattern from inside a workspace folder.

3. Add "open new/unreviewed repos in an isolated environment" to your onboarding docs and code review checklist, not as a suggestion, but as policy.

None of this fixes the underlying bug. Only Cursor closing off git.exe resolution to the actual system PATH, instead of also checking the workspace folder, does that. Until there's a shipped patch and a version number to point to, these steps just reduce your exposure.

The bigger question this raises

Set the specific bug aside for a second. The real story here is what happens when the tools we trust to write and manage our code start making autonomous decisions about which programs to run, and the company behind those tools goes quiet for months on a fully reproducible report.

Cursor isn't a niche tool. It's used by more than half the Fortune 500, according to the company's own marketing, and it's baked into daily workflows for millions of developers who've never had to think about "is my code editor itself a security boundary." That assumption, that your IDE is one of the trusted pieces in the chain, is exactly the one this bug breaks.

If you're building or relying on AI coding agents, whether that's Cursor, Copilot, or something you're wiring together yourself with n8n and a model API, this is a good prompt to ask a slightly uncomfortable question: what happens the moment that agent reads something you didn't write? A file in a repo, a page it fetched, an MCP tool response. If the answer is "it just... runs it," you have the same problem Cursor has right now, whether or not anyone's found it yet.

FAQ

Is this vulnerability patched yet? Not as of July 15, 2026. Cursor told Dark Reading it's addressing the issue but hasn't given a timeline or shipped a fix.

Does this affect Mac or Linux users? No. This specific flaw is Windows-only, tied to how Cursor resolves Git binaries on that platform.

Do I need to click anything for this to trigger? No. Simply opening a repository containing the malicious git.exe in Cursor is enough. No prompts, no approvals, no AI agent involvement required.

Is this the same as the DuneSlide vulnerability or CVE-2026-26268? No. Those are separate, already-patched Cursor vulnerabilities (fixed in versions 2.5 and 3.0 respectively). This git.exe workspace-lookup issue is a distinct, still-open bug.

What should I do if I've already opened untrusted repos in Cursor recently? Check for unexpected processes spawned by Cursor.exe using Task Manager or Process Explorer, review your SSH keys and cloud tokens for signs of misuse, and consider rotating credentials that were accessible from that machine if you have any doubt.

Has this been assigned a CVE number? Not as of publication, according to The Hacker News, which reviewed all of Cursor's published security advisories and found no entry covering this specific issue as of July 15, 2026.

This post covers a fast-moving security disclosure. Details, especially patch status, may change after publication. Check Cursor's official security advisories page before relying on any specific fix or version number mentioned here.