Cursor's Unpatched Git.exe RCE Still Hits Windows Devs

A developer on Windows opens a repository in Cursor. If that repo ships a file named git.exe in the root, Cursor runs it. No click, no dialog, no warning. The process can fire again while the project stays open.

That is the entire bug. Mindgard reported it on December 15, 2025. More than six months and 197-plus Cursor releases later, the behavior is still present in the latest version they tested. After private channels stalled, public full disclosure became the remaining way to warn the people actually at risk. For anyone using Cursor on Windows against untrusted code, the practical response is not "wait for a patch." It is to change how you open repos today.

How path resolution turns a repo into code execution

The technical root cause is path search, not AI magic. When Cursor loads a project, it looks for Git binaries in several places. One of those places is the workspace itself. On Windows, that means a git.exe planted at the repository root is a candidate. Cursor executes it as part of normal startup and ongoing operation, with no user approval step and no indication that executable content from the repo is about to run.

Mindgard's safe demonstration was blunt: rename Windows Calculator to git.exe, put it in the project root, open the folder in Cursor. Calculator launches. Leave the project open and more instances appear over time. The IDE is not running the binary once as a one-shot discovery. It keeps re-resolving and re-invoking workspace content during ordinary use.

In a real attack the payload is not Calculator. It is whatever the attacker ships under that name: a reverse shell, a credential stealer, a dropper. The only prerequisite is getting a developer to open the poisoned tree. That is a low bar. Clone-and-open is how open source, freelance handoffs, CI failure repros, and "can you take a look at this?" reviews work every day.

This is not a prompt-injection chain, a model jailbreak, or a multi-stage memory corruption. It is executable content from untrusted disk, treated as trusted tooling. That class of mistake is old. IDEs and build tools have been burned by workspace-local tools and hijacked PATH lookups before. Cursor's version is notable because the auto-execution is silent, repeated, and still shipping.

Why full disclosure landed here

Mindgard says it reported the issue the same day it was found, using the address in Cursor's published security.txt. Follow-ups went unanswered until Cursor's CISO eventually acknowledged an internal automation failure that had blocked the expected HackerOne workflow. The firm was invited into the private bounty program and resubmitted. The report was closed as Informative and out of scope, then reopened after challenge. HackerOne reproduced it and confirmed delivery to Cursor. After that: silence. Escalations and direct outreach to leadership produced no meaningful status.

Meanwhile Cursor kept shipping. Features, announcements, and version numbers moved. Dark Reading's coverage of the same disclosure notes the same gap: seven months on, no clear signal that users were warned, that remediation was underway, or that affected organizations were told. When a vendor neither patches nor communicates for that long on a no-interaction RCE, coordinated disclosure has already failed the people who need protection. Publishing the technical detail is then a pressure and warning mechanism, not a preference for drama.

That pattern sits in a wider 2026 climate where responsible-disclosure norms are under stress. Deadlines only work when vendors treat the clock as real. When they do not, researchers face a bad menu: stay quiet indefinitely, sell the bug, or go public and accept that unpatched users get exposed. Full disclosure of this Cursor issue is the least bad option after months of non-response, not a first resort.

What Windows Cursor users should do now

Until a fixed build is confirmed and you have upgraded, treat any untrusted or third-party repository as hostile on Windows hosts that run Cursor.

Consumer and solo machines

• Open untrusted projects only inside Windows Sandbox, a disposable VM, or another throwaway environment. Do not open them on your daily driver.
• Do not rely on hash blocklists. Attacker binaries will not match a fixed hash you pre-seeded.
• Prefer cloning and first inspection from a non-Cursor tool, then decide whether the tree is safe to open in the IDE.

Enterprise and managed Windows fleets

• Use AppLocker or Windows App Control to deny execution of the relevant executable name from developer workspace paths. Prefer path-scoped deny rules (for example patterns under %USERPROFILE%\source\repos\*\...) over hash rules, because hashes are attacker-controlled.
• Windows does not give you a simple built-in rule of the form "block this child only when parent is Cursor." Parent-aware policy usually needs EDR or a custom endpoint product. Plan for that gap.
• Document the exception process so legitimate local tooling is not permanently broken, but default-deny workspace-root executables matching Git's name.

Process habits that still matter

• Assume "open folder" is a trust boundary. It is for any IDE that resolves tools from the workspace; this bug just makes that boundary fail closed into RCE.
• Least-privilege developer accounts, constrained network egress, and logging of unusual child processes from the IDE reduce blast radius even when auto-execution slips through.
• If you manage a fleet of Cursor seats, inventory who is on Windows and who opens external code. That is your exposure set, not "everyone who has a license."

None of this replaces a vendor fix. It is what you do while the fix is absent.

AI IDEs are infrastructure. Their security process has to match

Cursor's user base is large enough that a silent Windows RCE is not a niche research footnote. The disclosure cites millions of active and paying users and tens of thousands of companies. At that scale, path-resolution bugs that execute workspace content are supply-chain adjacent: the attacker does not need to compromise Cursor's update channel. They only need one poisoned repo that someone opens.

Cursor has had other security findings in adjacent areas (configuration bypasses around ignore rules, extension-ecosystem risks, agent-driven execution paths). Those are separate issues. The common theme is worth stating plainly: tools that combine broad filesystem access, shell reach, and automated project loading are high-privilege runtimes wearing an editor UI. Security process has to treat them that way. A six-month non-response on a trivial auto-exec path does not.

The competitive pressure on AI coding environments rewards feature velocity. Path search order, workspace trust boundaries, and parent-aware execution policy are unglamorous. They are also the difference between "helpful Git integration" and "remote code execution on open." Vendors that skip the boring controls will keep shipping the same class of bug under new brand names.

Bottom line

The vulnerability is simple, live, and Windows-specific in its practical impact. Full disclosure happened because private reporting and bounty workflow did not produce a fix or a user warning. If you use Cursor on Windows, isolate untrusted repos and lock down workspace-root executables now. Do not wait for a changelog entry that may still be months away. When an IDE treats a repo-local git.exe as something to run automatically, the correct default is to assume the repo is the attacker until proven otherwise.