Sedenir.dev | Opening a folder in Cursor can run malicious code by itself

On Tuesday, July 14, 2026, security firm Mindgard published full technical details of a zero-day flaw in Cursor — the AI-powered code editor used by more than 7 million developers and over 1 million paying subscribers. The reason for going fully public wasn't to build an audience: it was the last resort after seven months of trying, unsuccessfully, to get the company to fix the problem.

How the attack works

The mechanism is disconcertingly simple. When Cursor opens a project on Windows, it searches for the Git binary in several locations — including inside the workspace folder itself. If an attacker plants an executable named git.exe in a repository's root, Cursor runs that file automatically as part of routine path resolution, with no confirmation dialog, no warning, no indication whatsoever that a binary from the repository itself is about to execute.

No AI, prompt injection, or social engineering required

Mindgard is emphatic on this point: exploitation doesn't depend on model manipulation, jailbreaks, indirect prompt injection, or any sophisticated tradecraft. All it takes is a developer opening a project that contains this forged git.exe at the root — something that happens constantly when reviewing open source code, evaluating a candidate during a technical interview, or collaborating with external contributors.

As a safe proof of concept, Mindgard renamed the Windows Calculator to git.exe and placed it at a repository's root. Simply opening the folder in Cursor was enough to trigger execution — repeatedly, on every internal Git query the editor makes, for as long as the project stayed open. In a real attack, that binary would be swapped for a credential stealer, a keylogger, or a ransomware loader, running with the same privileges as the logged-in user — including access to SSH keys, cloud tokens, and the source code itself.

The disclosure timeline

December 15, 2025 — Mindgard reports the flaw through Cursor's official security channel.
January 2026 — with no response, Mindgard tries reaching out via LinkedIn. Cursor's CISO replies, attributes the silence to a broken HackerOne automation, and personally invites Mindgard into the company's bug bounty program.
February 2026 onward — the flaw is resubmitted on HackerOne, confirmed reproducible by Cursor's own team. After that, total silence: status requests, escalations, and direct outreach to leadership go nowhere.
July 14, 2026 — after more than 70 new releases shipped without a fix (Mindgard puts the total at 197+ builds since the initial report), and still reproducible in version 3.2.16 as tested on April 30, the company decides on full disclosure.

Note

Cursor's security page promises to acknowledge vulnerability reports within 5 business days. Seven months passed. As Mindgard put it: "coordinated disclosure only works when there is coordination."

Not the first time — and not the last

Placed alongside other Cursor flaws revealed in 2026 alone, the pattern is concerning for anyone relying on the editor day to day:

January 2026 — CVE-2026-22708, fixed in version 2.3.
February 2026 — CVE-2026-26268, an escalation via Git hooks, fixed in version 2.5.
April 2026 — the "DuneSlide" vulnerabilities (CVE-2026-50548 and CVE-2026-50549), scoring 9.8 out of 10 on CVSS, resolved in version 3.0.
April 2026 — the "NomShub" chain, discovered by Straiker: indirect prompt injection via a README.md file combined with a sandbox bypass, abusing Cursor's built-in remote tunnel feature to give an attacker persistent shell access — requiring no user interaction beyond opening the malicious repository. On macOS, where Cursor runs without sandbox restrictions because its binary is signed and notarized, the impact was even greater.

The common thread

In none of these cases was the entry point the AI model itself being successfully manipulated — it was the automatic-execution surface surrounding the model: binary path resolution, Git hooks, remote tunneling features. It's the same category of risk already seen in npm supply chain attacks: implicit trust granted to anything inside a cloned repository.

Mitigations until a fix ships

What to do until Cursor patches it

Don't open untrusted repositories directly on the host. Use a disposable VM or Windows Sandbox for any project cloned from an external source.
On corporate Windows fleets, use AppLocker or Windows App Control with path-based deny rules — not hash-based ones, since the attacker's binary can carry any hash. A rule like %USERPROFILE%\source\repos\*\git.exe covers the pattern Mindgard described.
Monitor child processes of Cursor.exe that shouldn't exist; since Windows has no native way to block a child process based on its parent, this usually requires EDR tooling.
Audit cloned repositories before opening them. git.exe, npx.exe, node.exe, and where.exe have no business sitting at the root of a legitimate project.

The counterpoint: VS Code isolating its own agents

While the Cursor case exposes the risk of giving AI agents unrestricted filesystem access, VS Code moved in the opposite direction the very same week. Version 1.129, released days earlier, introduced the "agent host": Copilot, Claude, and Codex now each run in their own isolated process, built on the new Agent Host Protocol. Microsoft's stated justification is preventing a hung agent from freezing the entire editor — but the side effect is also architectural from a security standpoint: each agent becomes more contained, rather than sharing the same execution process as the main editor.

Placed side by side, the two cases show the same problem from opposite angles: as code editors embed AI agents with permission to run commands, read files, and spawn processes, the isolation architecture around those agents stops being an implementation detail and becomes a first-order security decision.

What this means for developers

Treat your AI editor as part of the attack surface, not just as a productivity tool — it has access at the same privilege level you do.
Be skeptical of repository trust dialogs. Cursor shows a "do you trust this repository?" warning when opening projects, but Mindgard hasn't publicly confirmed whether Git resolution runs before or after that check — which, in practice, may make the dialog cosmetic for this specific vector.
Favor process isolation and sandboxing when evaluating which editor or AI tool to standardize on in corporate environments, especially when handling third-party repositories or technical-interview candidates.
Track the CVE history of the tools you use, not just their latest version — a pattern of multiple critical flaws in the same year is a signal about architecture, not bad luck.

The Cursor case raises an uncomfortable question that goes beyond a single technical flaw: what does the actual security process look like at a $60 billion-valued tool used by more than half of the Fortune 500? Seven months of silence after a reproducible report isn't a footnote — it's the story.

Opening a folder in Cursor can run malicious code by itself — and Cursor has known for seven months