Rename Your Malware to git.exe. Cursor Will Run It For You.

The proof of concept is a renamed calculator

Security firm Mindgard reported this in December 2025: drop a binary named git.exe in the root of a repository, get a developer to open that repo in Cursor, and Cursor will execute it. Not "may prompt you to run it." Executes it. Immediately. Repeatedly, every time Cursor shells out to Git.

Their proof of concept wasn't even subtle — they renamed calc.exe to git.exe. Open the repo, and Calculator windows start popping up on their own.

4:25:12.6209706 PM Cursor.exe 54880 Process Create
c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe SUCCESS
Command line: git rev-parse --show-toplevel

That's it. That's the whole exploit. Cursor searches for a Git binary across several locations on Windows — including the workspace directory itself — and if your malicious git.exe sits there, Cursor finds it before it finds the real one. No sandbox check. No signature check. No "this binary is untrusted" dialog. As Mindgard put it: "There are no clicks, prompts, approval dialogs, or warnings. The result is arbitrary code execution."

Think about what that means in practice. Every "here's a repo, can you take a look" from a stranger, every CTF, every take-home assignment, every open-source contribution you casually git clone and pop open — all of it is now a potential RCE if the attacker bothered to read one blog post about how Cursor resolves binaries.

The timeline is the real story

The vulnerability itself is bad. Cursor's handling of it is worse:

• Dec 15, 2025 — reported to [e-mail]
• Jan 15, 2026 — a month of silence, then Cursor's CISO manually invites the researcher into the bounty program because the HackerOne automation broke
• Jan 16, 2026 — the report gets closed as "Informative and out of scope," then reopened
• Jan 20, 2026 — confirmed delivered, again
• Feb–Jun 2026 — five months of update requests. Nothing.
• April 30, 2026 — researchers confirm the bug still works, on version 3.2.16, after 197 released updates
• Jul 14, 2026 — full public disclosure, because coordinated disclosure stopped being a two-way street months earlier

197 shipped versions and the git-binary-hijack path never got touched. That's not an oversight, that's a company that doesn't have anyone's eyes on this class of bug. Full disclosure here wasn't the aggressive move — it was the last lever left after a vendor went dark for half a year on arbitrary code execution.

This isn't a Cursor problem, it's an agent problem

If this were one bug in one product, fine, ship a patch, move on. It's not. Look at what else landed in 2026:

• CVE-2026-26268 — an AI coding agent runs exploits the moment it touches a cloned repo, via crafted Git hooks
• DuneSlide (CVE-2026-50548 / CVE-2026-50549, CVSS 9.8) — zero-click prompt injection that escapes Cursor's sandbox entirely and executes on the host OS
• GhostApproval — the same failure mode across six different AI coding assistants, bypassing human-in-the-loop approval so the agent runs commands the user never actually approved

That's four distinct, serious vulnerability classes, across multiple vendors, all in the same twelve months, all rooted in the same design flaw: these tools grant an LLM the ability to execute shell commands, and then trust the repository content to tell it what's safe.

Git was designed assuming the person running commands understood what they were running. AI coding agents threw that assumption out — the "person" now is a model reading files in a repo it doesn't know is hostile, deciding on your behalf which commands to run, with your permissions, on your machine. A .git/hooks/post-checkout script or a binary named git.exe isn't a weird edge case to that model. It's just another file to read and, apparently, execute.

Every vendor in this space is racing to ship more autonomy — auto-run commands, auto-apply diffs, auto-resolve merge conflicts — faster than anyone is racing to audit what "autonomy" means when the input is an untrusted git repo. The agent is the attack surface now, and most of these companies are treating security reports like support tickets.

What to actually do about it

Stop assuming "just a repo" is inert. If you use Cursor, Copilot workspaces, Claude Code, Windsurf, or anything else that lets an agent execute shell commands against a checkout:

• Never open unknown or low-trust repos with agent-mode enabled. Read-only review first, agent second.
• On Windows specifically, lock down execution from workspace directories with AppLocker or Windows App Control. Don't rely on the IDE to do it for you — it won't.
• Untrusted repo? Disposable environment. Windows Sandbox, a throwaway VM, a container with no secrets mounted. Not your daily-driver machine with your SSH keys and cloud credentials sitting right there.
• Update aggressively, but don't trust updates as a security boundary. 197 releases shipped with this bug live. A version bump is not a patch confirmation.
• If you build agent tooling, binary resolution order and command execution paths need the same scrutiny as your auth code. "The LLM decided to run it" is not a security model.

The pitch for these tools is that they act like a very fast, very capable teammate. Start treating them like one you don't fully trust yet — least privilege, no unsupervised access to sensitive repos, and definitely no blind faith that the vendor caught the obvious stuff. Right now, several of them haven't.