On April 28, 2026, security researcher firm Novee Security disclosed CVE-2026-26268: a remote code execution vulnerability in Cursor, the $50 billion AI-native IDE. The National Vulnerability Database rated it CVSS 9.9 — critical. Cursor patched it in version 2.5 and issued its own severity assessment of 8.0, contesting NVD’s rating in a move that felt more like reputation management than technical disagreement.
The vulnerability is patched. Update to Cursor 2.5 if you have not. But the technical details of how this attack worked — and why it worked specifically against an IDE-embedded AI agent — deserve more attention than the standard “update your software” coverage has given them.
How the Attack Works#
The attack chain has three steps.
Step 1: Craft the repository. An attacker creates a legitimate-looking repository that contains an embedded bare repository (a .git directory inside the project). That embedded bare repo includes a pre-commit hook containing malicious code.
Step 2: Exploit Cursor’s insufficient sandbox. Cursor runs its AI agent in a sandbox — but the sandbox failed to protect .git directory configurations from write operations. A malicious agent, triggered via prompt injection (a carefully crafted comment, README, or code file the agent reads), could write to .git/hooks/pre-commit without triggering a permission prompt or warning.
Step 3: Wait for git. The next time Cursor’s agent — or the developer — runs a git commit or git checkout operation inside the embedded repository, the hook fires automatically. The hook runs with the full privileges of the Cursor process. The developer’s workstation executes attacker-controlled code.
No confirmation dialog. No permission prompt. No indication anything unusual happened. The hook fires because that is what git hooks do.
Cursor classified the root cause as CWE-862: Missing Authorization — the sandbox did not properly restrict write access to .git configuration files. The fix in 2.5 implements proper authorization controls to prevent this write path. That is the correct patch for this specific vulnerability.
It does not fix the class of problem.
Why IDE-Embedded AI Is Structurally More Exploitable#
Novee’s disclosure contains an observation that deserves to be read carefully:
“Traditional IDEs are passive, doing what developers explicitly tell them to do. Cursor’s AI agent interprets intent and autonomously decides which commands to run — which includes git operations.”
This is the crux. A traditional IDE could be misconfigured by a malicious repository, but the developer would have to explicitly run a command to trigger a malicious hook. The attack surface requires human action.
An IDE-embedded AI agent changes the threat model in two ways:
1. The agent decides autonomously which commands to run. When Cursor’s agent is working on a task, it reads files, infers intent, and executes git operations as part of completing that task. A prompt injection payload — embedded in a README, a comment, a variable name, or a docstring — can influence those decisions without any developer interaction. The agent reads the file, the injection fires, the agent executes the operation, the hook runs.
2. The process inherits native system access. Cursor runs as a desktop application with your full user-level permissions. It can read your SSH keys, your environment variables, your .aws/credentials, your browser cookies, your source code — anything your user account can access. When the sandboxed agent writes to a git hook and that hook fires, the code runs as Cursor, which runs as you.
The sandbox between the AI agent’s reasoning layer and the host system is the only barrier. CVE-2026-26268 is a specific instance of a prompt injection attack defeating that barrier via a git hook. The next CVE will find a different path through the same architecture.
The Terminal-Native Contrast#
Claude Code’s architecture starts from a different premise. There is no IDE wrapper. The agent is a terminal process. It has the permissions you grant it when you run it, and those permissions are explicit in the CLAUDE.md configuration and the per-session approval flow.
When Claude Code needs to run a git operation, it uses the Bash tool — which is visible in the session transcript, auditable, and (in default mode) subject to approval before execution. Prompt injection can still occur, but the attack surface for an injected payload is the bash tool approval layer, not a hidden hook that fires silently on the next git operation.
This is not to say Claude Code is immune to prompt injection. No AI agent that reads arbitrary files is immune to prompt injection. But the architecture determines how hard it is to weaponize a successful injection into actual code execution.
| Factor | Cursor (IDE-embedded) | Claude Code (terminal-native) |
|---|---|---|
| Process privileges | Full desktop-app user-level access | Terminal user-level access |
| Tool execution visibility | Determined by sandbox implementation | Tool call visible in session transcript |
| Hook/background trigger surface | Git hooks, IDE extensions, file watchers | Bash tool (auditable) |
| Blast radius if sandbox fails | Full workstation compromise | Same, but the sandbox is shallower |
The sandbox in a desktop AI IDE has to protect against a much wider attack surface than a terminal agent — because the IDE itself runs with broad system integration by design.
What Happened After Disclosure#
Novee disclosed the vulnerability privately to Anysphere (Cursor’s parent company) before publishing. Cursor patched it in version 2.5. So far, standard responsible disclosure.
The controversy is over the severity rating. NVD assigned CVSS 9.9. Cursor published its own CVSS analysis scoring the vulnerability at 8.0, arguing the attack requires prompt injection as a prerequisite — which it categorizes as a separate vulnerability class — reducing the attack complexity score.
This is technically defensible but practically misleading. Prompt injection is not a separate attack that happens first and then this vulnerability separately requires exploitation. Prompt injection is the mechanism by which the malicious agent behavior is triggered. Treating them as independent events understates how easily the full attack chain executes in practice: open a malicious repository in Cursor, let the agent read the README, watch a hook get written.
The 9.9 vs 8.0 debate matters for enterprise security teams tracking CVE severity. For developers, the practical conclusion is the same either way: critical enough to patch immediately.
Cursor Is Not Alone#
Fairness requires noting that Cursor is not the only IDE-embedded AI tool with a git hook attack surface. Any AI agent that:
- Runs inside a desktop process with broad system access
- Can write to the filesystem (including
.gitdirectories) - Reads arbitrary files for context
…has a version of this risk. Cursor got the CVE because Novee found the specific write path to .git/hooks. Other IDE-embedded agents have similar surfaces.
The Hacker News thread on CVE-2026-26268 produced a good question: “Has anyone checked whether Windsurf or Copilot have the same .git write path?” No published disclosure as of this writing, but it is the right question to ask.
What makes Cursor specifically notable here is the combination of scale ($50 billion valuation, 1 million users, rapid enterprise adoption) and the aggressive expansion of autonomous agent capabilities — including the Cursor SDK that allows programmatic agent invocation. More autonomous capability, running in the same process with the same system access, means more surface area for the same class of attack.
What Developers Should Do#
Immediately:
- Update Cursor to version 2.5 or later. This is the specific patch for CVE-2026-26268.
- Audit which repositories your Cursor agent is allowed to operate in. Treat unknown repositories the same way you would treat unknown npm packages.
Structurally:
- Understand that an AI agent that runs inside your desktop application with your user-level permissions is categorically different from a sandboxed cloud agent. The blast radius of a successful prompt injection is your workstation.
- Review your CLAUDE.md (or equivalent agent configuration) to understand what tool access you have explicitly granted. For Claude Code users, the
denyrules insettings.jsonand theBashtool approval flow are the relevant controls. - Consider whether the workflows where you need autonomous git operations from your AI agent actually require that agent to run inside a process with full desktop privileges.
The Bigger Question#
CVE-2026-26268 will be fixed in most Cursor installations within a few weeks as users update. The next vulnerability will emerge — not because Anysphere is careless, but because the architecture puts an autonomous reasoning system inside a privileged desktop process, and the space of ways that can go wrong is large.
The terminal-native model that Claude Code uses does not eliminate this risk. But it does change the threat model in a meaningful way: a terminal process is expected to execute commands, and those commands are visible and auditable by design. A desktop AI IDE inherits all the attack surface of a desktop application plus all the attack surface of an autonomous AI agent — in the same process, with the same permissions.
That is a structural property of the architecture, not a bug any single patch can fix.
Sources:
- CVE-2026-26268: How an AI Coding Agent Can Run Exploits in Cursor IDE — Novee Security
- CVE-2026-26268 Detail — NVD
- CVE-2026-26268: Anysphere Cursor Sandbox Escape RCE Flaw — SentinelOne
- Critical Cursor bug could turn routine Git into RCE — CSO Online
- Cursor AI IDE vulnerability allows code execution via hidden Git hooks — HackRead
- Critical Cursor Vulnerability Exposes Developer Workstations To Remote Code Execution — CyberPress