A Cursor git.exe vulnerability lets a single renamed file hijack any Windows machine running the popular AI coding tool. Seven months after a researcher reported it, there is still no fix. AI security firm Mindgard published full technical details on July 14, 2026. It concluded that private disclosure had gone nowhere.
The bug sits in how Cursor resolves the Git binary when it opens a project on Windows. The IDE checks several locations for git.exe. One of them is the root of the workspace itself. Drop a file called git.exe into a repository’s top-level folder. Cursor runs it the moment a developer opens that folder. No prompt. No warning. Nothing to click through.
Inside the Cursor git.exe vulnerability
Mindgard proved the point with the plainest possible demo. It renamed the Windows Calculator app to git.exe and dropped it at the root of a test repository. Opening that folder in Cursor was enough. Process monitor logs showed Cursor.exe repeatedly launching the fake binary. It issued commands like git rev-parse --show-toplevel, exactly as it would with a legitimate Git install.
Swap the calculator for a real payload, and the attacker gets code execution under the developer’s own account. That opens a path to source code, SSH keys and whatever cloud tokens sit on the machine. Cursor keeps calling the binary while the project stays open. One careless clone can lead to repeated, silent re-execution.
For a threat actor, this is a cheap and reliable delivery method. Cloning an unknown public repository is routine behaviour for developers, researchers and open-source contributors alike. It needs no phishing email and no social engineering beyond a repository worth cloning.
Seven months, no patch, no advisory
Mindgard reported the issue to Cursor’s security inbox on December 15, 2025, then followed up three days later. Cursor’s CISO manually invited the researcher into a private HackerOne bounty program on January 15, 2026. The report was closed the next day as “informative and out of scope.” It was reopened only after Mindgard pushed back and showed the bug again. HackerOne confirmed the report had reached Cursor on January 20.
After that, the trail goes quiet. Mindgard sent status requests in February, March and April, with no real reply. On June 1, it warned Cursor it intended to go public. On July 14, it did. Cursor has still not published an advisory covering the flaw among its 33 public advisories. No CVE ID has been assigned.
Mindgard framed the decision bluntly. Full disclosure, it said, is “the nuclear option of vulnerability disclosure,” reserved for when every other path has failed.
Not just a Cursor problem
Cymulate’s research lab found the same Cursor git.exe vulnerability pattern across a wider set of AI coding assistants in June 2026. GitHub Copilot CLI, Google’s Gemini CLI and OpenAI’s Codex app all showed the same unsafe binary resolution behaviour on Windows. Each one executed a planted git.exe, or a similar tool, from the workspace before any trust check ran.
AWS’s Kiro had a related but distinct issue: arbitrary command execution through a poisoned .vscode/tasks.json file. It was reported to AWS on February 2, 2026. That one got a CVE, CVE-2026-10591, rated 8.8 on the CVSS scale. AWS shipped a fix in version 0.11 and published an advisory. Cymulate’s vendor scorecard was blunt about the contrast. AWS engaged and fixed its bug. GitHub downgraded its report to low severity with no committed remediation. Cursor and OpenAI closed their reports without any real technical response.
A repeat pattern, not a one-off
This is not the first time Cursor has been caught out by workspace trust design. A separate, already-patched issue, CVE-2026-26268, was a maximum-severity Git-hook sandbox escape affecting Gemini CLI. It was fixed in Cursor 2.5 earlier this year. The pattern repeats because the same assumption keeps returning. A cloned repository, it assumes, can be trusted enough to execute code from.
Cursor is not a niche product. It counts more than 7 million active users, over a million paying customers and adoption at more than 50,000 companies. The figures come from Mindgard’s writeup. That scale turns an unpatched, ignored bug into a live risk, not an academic one. It matters most for anyone who reviews or builds on code they didn’t write, for a living.
It also fits a wider trend this outlet has flagged before. An Amazon Q developer vulnerability disclosed in June showed the same root cause. An AI coding tool auto-executed something in a workspace before it established any trust boundary. Different vendor, same design gap: the same Cursor git.exe vulnerability class is spreading across the market.
What defenders should do now
Until Cursor ships a fix, treat any outside repository as untrusted input to the IDE itself. That applies to the tool, not just the code inside it. Open unfamiliar clones in a disposable VM or Windows Sandbox rather than your main workstation. Before opening a clone anywhere else, check the repository root for unexpected executables such as git.exe, npx.exe, node.exe or where.exe.
Organisations managing Windows developer fleets should look at AppLocker or Windows App Control deny rules that block execution from workspace paths. Make sure EDR tooling can enforce policy based on parent process, not just the executable name. None of these steps fixes the root cause. Only Cursor can fix the Cursor git.exe vulnerability, and so far it hasn’t.
