Cursor Patched a Silent Repo-Poisoning Zero-Day With No Advisory and No CVE
Clone a stranger’s repository and open it in Cursor on Windows. That is the entire exploit. If the repository contains a file named git.exe at its root, the AI IDE runs it immediately — no click, no approval dialog, no warning — with the full privileges of the logged-in developer. The attacker’s code executes, and it keeps executing, repeatedly, for as long as the project stays open.
Cursor quietly fixed this on July 13, 2026, one day before AI security firm Mindgard published its full technical writeup after a seven-month disclosure process that produced silence, a broken bug bounty automation, an initial rejection, and no status updates. As of July 17, the company has issued no public security advisory, assigned no CVE, and told no one which version number contains the fix, according to reporting by Dark Reading and The Hacker News.
Cursor serves more than 7 million active users, more than 1 million daily active users, and more than 1 million paying subscribers across more than 50,000 companies. Developers who have not updated to the patched build are unaware they were ever at risk.
What Developers Running Cursor on Windows Should Do Right Now
Update Cursor immediately. The company told Dark Reading it addressed the issue on July 13, but has not publicly identified the patched version number. Updating to the most recent available build is the only confirmed mitigation.
For managed Windows environments where an immediate update is not possible: administrators can deploy AppLocker or Windows App Control path-based deny rules scoped to developer workspace directories — for example, %USERPROFILE%sourcerepos*filename.exe — to block execution of any file named git.exe originating from a repo root. Hash-based blocklists will not work, because an attacker can vary the binary’s content. Windows provides no native parent-process-aware rule to block a child process only when a specific application launches it; parent-aware enforcement requires EDR or a custom endpoint security product.
For individual developers on unpatched builds: open untrusted repositories only in Windows Sandbox or a disposable virtual machine until the update is applied.
For MCP-related exposure from the Adversa AI findings disclosed July 15: allowlist MCP servers through Cursor’s managed settings so only organization-vetted servers can be installed, and block cursor://…/mcp/install URI patterns at email and web gateways.
How Cursor Ran Attacker Code From a Cloned Repo
The mechanism is CWE-426 — an untrusted search path — applied to a behavior specific to AI IDEs. When Cursor loads a project on Windows, it issues a standard Git introspection call, git rev-parse --show-toplevel, to locate the repository root and orient itself within the project structure. To do that, it needs a Git binary. It searches several locations for one, and that search includes the workspace itself — the project directory the developer just opened.
Windows resolves unqualified command names using a search order that historically included the current directory before system paths. An attacker who plants a file named git.exe at a repository root exploits exactly this behavior. When Cursor invokes git, it finds the attacker-supplied binary first. It runs it. Whatever the binary does, it does with the developer’s credentials — their SSH keys, their cloud tokens, their access to source code and CI pipelines.
Mindgard demonstrated the flaw with the Windows Calculator application, renamed git.exe and committed to a repository root. Simply opening the project in Cursor was enough to launch Calculator. What made the proof-of-concept striking was the repetition: Cursor kept re-invoking the binary throughout the session, causing Calculator windows to multiply on screen while the project remained open. In a real attack, the calculator would be replaced with a remote access trojan, ransomware, or a credential-harvesting payload.
This is not a new vulnerability class. CWE-426 (untrusted search path) has been a documented and named weakness since 2006. The directly analogous prior case is CVE-2020-26233, which affected Git Credential Manager Core in 2020: a malicious git.exe at a repository root, executed during a recursive clone. The proof-of-concept for that case was also calc.exe renamed git.exe. Security researchers at Blaze Information Security documented it. Six years on, the same technique landed against an AI IDE that issues the git probe automatically the moment a developer opens a folder — because AI IDEs need repository context to function, and that architectural requirement rebuilds the attack surface that CWE-426 describes.
A Seven-Month Paper Trail of Non-Engagement
Mindgard discovered the flaw on December 15, 2025, and reported it the same day to Cursor’s published security email address. No confirmation arrived. A follow-up went out December 18. No response.
By January 2026, Mindgard posted publicly on LinkedIn to find a security contact at the company. Cursor’s CISO responded, acknowledged that an internal automation failure had prevented the expected HackerOne workflow from triggering, and manually invited Mindgard to the private bug bounty program. The report was resubmitted. Within days, evaluators closed it as informative and out of scope.
Mindgard challenged that determination. HackerOne reopened the report, reproduced the vulnerability, and confirmed on January 20 that the details had been delivered to Cursor. After that, the process stopped. Update requests in February, March, and April received no replies. Direct outreach to Cursor leadership produced no response.
During those same months, Cursor’s advisory process functioned for at least one other researcher. On February 13, 2026, the company published GHSA-8pcm-8jpx-hv8r, a Git-hook sandbox escape (CVE-2026-26268) reported under coordinated disclosure and fixed in Cursor 2.5. Three days later, Mindgard asked for an update on its own Git-related report. No reply came.
On June 1, 2026, Mindgard informed HackerOne that it intended to go public. The full technical disclosure landed July 14 — 213 days after the initial report, and 197 or more new Cursor releases after the flaw was first described to the company.
Aaron Portnoy, Mindgard’s Chief Product Officer, wrote the disclosure post. He is the architect of the first six Pwn2Own competitions and spent years running the Zero Day Initiative — the primary institutional infrastructure for responsible vulnerability disclosure before HackerOne existed. “Full disclosure is the nuclear option of vulnerability disclosure, reserved for situations where every other path has failed,” Portnoy wrote. “Rapid growth introduces a responsibility to address security failures while also requiring the treatment of users as valuable customers, not buying experiments.”
Cursor’s formal response to Dark Reading, published in an updated July 16 article, offered a structural defense rather than an explanation of the delay: the company invoked a “shared responsibility model” for workspace and agent-context inputs, arguing that customers decide which repositories, prompts, external content, MCP servers, rules, and tools to introduce into their environment, and that issues depending on compromised or malicious inputs already present in that context generally fall outside its bug bounty scope.
The same-class binary-planting issue was not unique to Cursor. Cymulate documented it in June 2026 across GitHub Copilot CLI, Gemini CLI, and the Codex desktop app — all searching their working directories for helper binaries. As of Cymulate’s June 4 publication, none of those vendors had shipped a fix. GitHub paid a bounty but downgraded the severity to low. Google agreed the Gemini CLI finding was valid and released no patch. OpenAI closed the Codex report as not applicable, arguing that an attacker who can replace git.exe already has system access — a position that mischaracterizes the attack, which requires only that a developer clone a repository, not that the attacker have any prior foothold.
Adversa AI’s Same-Day Follow-On: DeepJack and MCP Install Spoofing
Mindgard’s disclosure was barely a day old when Adversa AI published a separate report on July 15, 2026, documenting two additional attack vectors in Cursor — this time targeting the cursor:// URL scheme handler that Cursor registers on the operating system during installation.
The attack class is called DeepJack. It exploits the MCP server installation flow rather than the Git path. When a cursor:// deeplink targeting the mcp/install endpoint is clicked, Cursor opens an installation dialog asking the user to approve a new MCP server and the command it will run. That dialog is the only consent checkpoint between a clicked link and an attacker-controlled process running with the developer’s full privileges.
The first DeepJack variant exploits the dialog’s single-line text box. Adversa AI padded a visible argument with a long run of tab characters, then appended a malicious trailing command. In the dialog, the tab run pushes everything after it off the right edge of the text field, out of view. The user reads a short, benign-looking string, clicks approve, and Cursor executes the full argument including the hidden tail — including any shell command the attacker appended.
The second variant is more socially sophisticated. Adversa AI used double-URL encoding to embed an mcp/install URI inside a link that presents as a standard pr-review request. The link reads as a routine “review this pull request” notification — exactly the kind of notification developers receive from GitHub, Linear, and Jira continuously. Clicking it opens Cursor, which parses the outer pr-review request normally. But Cursor does not recursively decode or revalidate the url parameter, so the nested mcp/install URI rides through validation and reaches the install handler. The user receives the same installation dialog as the first variant, still without seeing the full command.
Cursor closed both Adversa AI reports as duplicates of earlier-filed issues. Triage noted explicitly that the root cause — the single-line text box that allows command content to scroll out of view — had been filed internally on April 27, 2026. As of July 15, Cursor 3.9.8 remained vulnerable. The company had known about the dialog’s structural weakness for roughly two months without shipping a fix.
The weakness class is not new. Argument injection through a custom URL-scheme handler is documented in CWE-88 and CWE-939 and has prior art in the Windows ms-officecmd:// drive-by RCE and earlier browser-exploitation history. Platform guidance predating the term “agentic AI” already specified the fix: treat every incoming parameter as hostile, and confirm any dangerous action by displaying to the user what will actually execute. Cursor’s dialog implements a version of that confirmation that cannot be relied upon when the displayed content is attacker-controlled.
The Attack Surface No Enterprise Team Is Watching
Every major AI coding agent installs a custom URL scheme handler on the developer’s operating system. Cursor registers cursor://. VS Code registers vscode://. Claude Code registers claude-cli://. Codex registers codex://. Warp registers warp://. Adversa AI surveyed these handlers across agents and found that most expose a route that ends in an install-or-execute action: the mcp/install route in Cursor and VS Code, a launch-config route in Warp that can carry commands, a registry-install route in Windsurf.
Adversa AI found that enterprise security teams were typically unaware these handlers were registered at all — a documented attack surface receiving almost no scrutiny while the louder security conversation focused on prompt injection and MCP supply-chain attacks.
The broader MCP vulnerability landscape is substantial. As of May 2026, at least seven confirmed high- or critical-severity CVEs spanned major MCP-integrated platforms including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf. The MCPoison attack class (CVE-2025-54136), disclosed in August 2025, demonstrated persistent code execution in Cursor IDE through a trust-caching mechanism that stored MCP server approvals without re-validating them on subsequent connections.
The reason developer workstations are the focus of this research is not abstract. A developer’s machine typically carries SSH keys, cloud provider credentials, live session tokens, source code containing intellectual property, and direct access to CI/CD pipelines and production infrastructure. A binary-planting flaw that would be a nuisance on a general-purpose machine is, on this endpoint, a foothold in the software supply chain. The blast radius is close to total.
What Cursor’s Accountability Deficit Means for the AI IDE Ecosystem
The git.exe flaw’s persistence for seven months across 197 or more new releases — while Cursor simultaneously processed and published other security advisories — points to something more specific than general security immaturity. It points to a triage culture that treated a reproducible, arbitrary code execution vulnerability affecting 7 million users as a lower priority than feature development, and a disclosure process that required full public disclosure to produce a silent patch without user communication.
Portnoy’s framing is the most precise available: “Trust requires accountability, and accountability requires communication. When users, researchers, and disclosure platforms spend months seeking basic status updates without success, that accountability becomes difficult to see or believe in,” he wrote.
Cursor is not the only AI IDE with documented trust-model failures this month. The GhostApproval symlink class, documented July 10 by a separate research team, demonstrated how six different AI coding tools — including Cursor, Claude Code, and Amazon Q Developer — could be manipulated into writing attacker-controlled SSH keys to a developer’s machine through symlink abuse in approval dialogs. The HalluSquatting attack class, documented July 13 by researchers from Tel Aviv University and Technion, demonstrated how AI coding assistants’ documented tendency to hallucinate package names reaches 85% exploitation success when attackers pre-seed the identifiers.
These are not coincidental. They are independent research teams converging on the same underlying condition: AI coding tools have been granted extraordinary trust over developer machines — terminal access, cloud credential access, shell execution — while the security models governing that trust have not kept pace with the tools’ capabilities. The git.exe flaw is, in Mindgard’s own assessment, almost boring in its simplicity. That may be the most important thing about it.
Frequently Asked Questions
Is my Cursor installation still vulnerable to the git.exe flaw?
If you are running Cursor on Windows and have not updated since July 13, 2026, you may be running an unpatched build. Update Cursor immediately. Cursor told Dark Reading it addressed the issue on July 13, but has not publicly identified which version number contains the fix. Update to the latest available build. If you regularly open repositories from external sources — GitHub, open-source projects, candidate coding assessments — prioritize this update.
What can an attacker actually do if they exploit this?
A git.exe planted at a repository root runs with the full privileges of the developer who opened the project in Cursor — not sandboxed, not restricted, not prompted. That means access to everything the developer’s account can reach: source code, SSH keys, cloud provider credentials, live session tokens, browser cookies, any secrets stored on the machine. The payload also persists: Cursor re-executes the binary repeatedly throughout the session, not just once.
What is the DeepJack vulnerability, and is it patched?
DeepJack is a vulnerability class documented by Adversa AI on July 15, 2026, in which a crafted cursor:// deeplink installs an attacker-controlled MCP server on a developer’s machine after one click and one confirmation. The install dialog’s single-line text box allows an attacker to hide a malicious trailing command off the right edge of the visible area using whitespace padding. Cursor confirmed the root cause internally on April 27, 2026 — two months before Adversa AI’s publication. As of July 15, 2026, it remained unpatched in Cursor 3.9.8.
Why didn’t Cursor inform users about the patch?
Cursor has not publicly explained why no security advisory or CVE was issued alongside the July 13 fix. The company’s formal response invoked a “shared responsibility model” arguing that issues requiring a malicious input already present in the workspace are out of scope for its bug bounty program. No public communication to users about the vulnerability or the fix has been issued as of July 17, 2026. Developers who rely on Cursor’s advisory record or vulnerability databases to track security issues would have no record that this event occurred.
