Mindgard: Cursor still runs git.exe from repo root

The bug lives in how Cursor resolves helper binaries on Windows. When the editor loads a project, it wants to know the repository root, so it invokes git rev-parse --show-toplevel. To find git for that call, it relies on Windows’ default executable search order — the one that checks the current working directory before it walks %PATH%. If a file named git.exe is sitting at the project root when Cursor opens the folder, Cursor runs it. No workspace-trust dialog. No prompt. No warning that the folder is about to execute code. Whatever that binary does, it does as the logged-in user, with the running session’s source, SSH keys, and cloud tokens. Cursor keeps re-invoking it for as long as the project stays open — Mindgard notes the same path is walked repeatedly through the session, not just once at load.

Mindgard, an AI-security firm, published the full disclosure today. The primary author is Aaron Portnoy, who ran the original Zero Day Initiative and built the first six Pwn2Own contests. He reported the flaw to Cursor on 2025-12-15 through HackerOne. Cursor’s triage closed it “Informative and out of scope”; Portnoy pushed back and the report was reopened. Reproducibility was confirmed on 2026-01-20. Cursor gave update commitments in February, March, and April, and delivered nothing. Mindgard verified the bug present on 2026-04-30 against Cursor 3.2.16 and says the current release, 3.11 (2026-07-10), still ships it. No CVE has been assigned. Cursor has published no advisory.

Not just Cursor

Mindgard tested the same class across four other AI coding tools and reports the same execution path in GitHub Copilot CLI, Google Gemini CLI, and OpenAI Codex — invoked helper resolves relative to the workspace before absolute install locations. GitHub triaged its report as low severity. Google shipped no patch. OpenAI closed the report as “Not Applicable.” Two earlier bugs sit in the same family and did get fixed: CVE-2020-26233 closed the same primitive in Git Credential Manager Core, and Cursor’s own CVE-2026-26268 closed a related git-hook sandbox escape in Cursor 2.5. This one is the same shape at a different layer.

Who is exposed

The condition is narrower than “everyone who runs Cursor” but wider than most Windows Cursor users assume. It is anyone who opens a folder in Cursor on Windows where the folder’s contents came from somewhere the reader has not personally audited. In practice:

1. Public-repo review — pulling down a fork to look at a PR, cloning a security researcher’s write-up repo, opening a talk’s sample code. This is the fattest population by far. It is also the one where telling the user “just don’t open untrusted repositories” collapses on contact with what the tool is for.
2. Contractor and internship intake — a Windows laptop with Cursor installed opens the first project handed to it. The trust boundary is a hiring decision, not a technical one.
3. CI scratch clones inspected on a developer box — a build failed, a developer clones the offending branch locally to look. That branch’s contents get one glance in Explorer before Cursor opens the workspace.

macOS and Linux are not exposed in the same way. The bug is specifically the Windows CreateProcess search order preferring the caller’s current directory when a bare filename is passed. On Unix, Cursor resolves git through PATH and the current directory is not on PATH by default.

What to actually do

Cursor has not shipped a fix, so the mitigations here are all workarounds:

• Do not open unknown Windows repositories in Cursor until Cursor ships a resolver change. This is the one line that actually removes the exposure.
• Scan cloned trees before opening. Mindgard calls out git.exe, npx.exe, node.exe, and where.exe at the workspace root as the obvious canaries; the general rule is any Windows executable in a location an IDE is about to walk. Get-ChildItem -Recurse -Include *.exe,*.bat,*.cmd,*.ps1 -Depth 2 from PowerShell against a fresh clone is enough to catch the loud cases.
• AppLocker or Windows App Control deny rules blocking executable launch from paths under a designated “workspaces” folder. This is the correct enterprise mitigation and it holds across every editor and CLI Mindgard names, not just Cursor.
• Windows Sandbox or a disposable VM for anything genuinely unknown. Slower and better than the workaround above.

There is nothing to do on the Cursor configuration side — no workspace-trust setting, no “prompt before running helpers” toggle. The behavior is unconditional.

The pattern

The interesting piece is not the bug — it is a well-understood Windows resolution quirk with a well-understood mitigation, and it will get fixed. The interesting piece is that a coordinated disclosure with a reproducible walkthrough from a named senior researcher, escalated repeatedly through the vendor’s own program, sat unmoved for seven months while shipping across nine releases. That is the shape that keeps coming up in this class of tool. See GhostApproval, where symlinks let six AI coding assistants approve one file and write to another, and Friendly Fire, where the agents were tricked into executing a hidden binary during their own security-review pass. The trust boundary each of these tools has to draw is between the human running the tool and the code the tool has been pointed at, and every one of them so far has drawn it on the tool’s side rather than the workspace’s — and been slow to redraw it once told.

The fix, when Cursor writes it, is a two-liner: resolve helper binaries by absolute path from a trusted install location, refuse to fall through to the current directory. That is a change to a single call site in the git-detection code. It is not shipped today, seven months in.

Related coverage

• GhostApproval: symlink bug hits six AI coding assistants — Wiz’s earlier disclosure across the same class. Different primitive, same trust-boundary miss.
• Friendly Fire: agents review the trap, then execute it — Claude Code and Codex executing hidden payloads during a security-review pass.
• Ghostcommit and the reviewers that don’t open the PNG — one layer up the same pipeline, prompt-injection from a repository asset.

Sourcing

• Mindgard. Cursor 0day: When Full Disclosure Becomes the Only Protection Left, 2026-07-15.
• The Hacker News. Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution, 2026-07-15.
• Microsoft Learn. CreateProcessW — search order for executable filenames.
• Prior related fixes: CVE-2020-26233 (Git Credential Manager Core), CVE-2026-26268 (Cursor git-hook sandbox escape, fixed in Cursor 2.5).