CVE-2026-26268: Git Hooks as a Sandbox Escape in Cursor

TL;DR

Impact Cursor before 2.5. Insufficient write protection on .git config and Git hooks leading to out-of-sandbox RCE

Action Update to Cursor 2.5+. Audit .git/hooks/ and Git config in existing repositories

Update On April 28, 2026, Novee published details on the attack path. The focus is on embedded bare repositories and Cursor Rules in malicious repos

CVE-2026-26268 in Cursor was patched back in February 2026.
But when Novee published a detailed write-up of the attack path on April 28, it became more than just “update your old Cursor.”

The core issue is that AI agents run Git operations autonomously.
If a human reads the output and manually types git checkout or git commit, Git hooks are just a normal automation feature that has existed for decades.
When an AI agent reads instructions from inside a repository and fires off Git operations on its own, though, the .git directory stops being “config” and becomes an execution boundary.

In Cursor before 2.5, a malicious agent inside the sandbox — say, one that had been prompt-injected — could rewrite the insufficiently protected .git config.
If it could also write to Git hooks, the next time Git fired that hook, code ran outside the sandbox.
The GitHub Advisory marks this as “No user interaction” because Git executes hooks automatically — no extra click or confirmation needed.

Git hooks become an execution boundary

Git hooks are scripts that run automatically on events like pre-commit, post-checkout, and pre-push.
In normal development they run formatters, tests, and commit message checks. Useful, but what actually executes is just a shell script.

The point here is not that Git hooks are some new capability.
What makes this dangerous is the combination with AI coding agents that read repository contents as “work instructions” and autonomously execute Git operations.

In Novee’s write-up, the attack embeds a bare repository (a Git repository with no working tree) inside the malicious repo, with malicious hooks inside it.
Cursor Rules then steer the agent’s behavior so that it runs Git operations as part of its normal workflow.
The hook fires as a legitimate Git feature.

flowchart TD
    A["Open malicious repository"] --> B["Cursor Rules steer<br/>agent behavior"]
    B --> C["Agent executes<br/>Git operations"]
    C --> D["Git hook inside embedded<br/>bare repository fires"]
    D --> E["Arbitrary code execution<br/>on developer machine"]

    style E fill:#991b1b,color:#fff

Like Clinejection, this is not just about telling an AI to “do something malicious.”
When existing building blocks — natural language, CI/CD, Git, npm, IDE config — connect, trust boundaries shift somewhere.
In CVE-2026-26268, that shift happened between the local IDE and Git hooks.

Two different CVSS scores

The GitHub Advisory rates CVE-2026-26268 as High with a CVSS 3.1 score of 8.0.
The vector is CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H, with attack complexity and required privileges set high.

NVD, on the other hand, assigned 9.9 Critical in its initial analysis on February 18, 2026.
Its vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
Same CVE, but GitHub as the CNA and NVD disagree on the attack prerequisites.

The gap is significant.
GitHub treats “a malicious agent can write to .git config” as a high bar.
NVD seems to evaluate the scenario where an AI IDE opens a repository and an agent operates inside it as a lower barrier.

Personally, if your workflow involves opening unknown repositories in Cursor, the NVD reading is closer to reality.
An AI agent’s “convenient automatic execution” is, from an attacker’s perspective, a mechanism that skips human confirmation.

If you were on pre-2.5, updating alone is not enough

The fix shipped in Cursor 2.5.
For fresh machines, updating is sufficient.

If you previously opened unknown repositories with Cursor before 2.5, check .git/hooks/ in those repos.
Look for unexpected pre-commit, post-checkout, post-merge, or pre-push hooks.
Scripts with execute permissions, obfuscated shell code, outbound network calls, curl | sh, osascript, PowerShell, or credential-reading logic should be preserved for investigation before deletion.

Also check Git config.
If core.hooksPath points somewhere unexpected, checking only .git/hooks/ will miss it.

git config --local --list --show-origin
git config --local --get core.hooksPath
ls -la .git/hooks

On machines with multiple repositories, prioritize the working directories you recently opened in Cursor.
Developer machines tend to have GitHub tokens, npm tokens, cloud credentials, and SSH keys lying around, so local RCE is not just a “lateral movement” problem — it is the front door.

Sandboxes need to treat Git specially or they become escape hatches

In local sandbox execution for AI agents, I wrote about constraining the filesystem with macOS sandbox-exec and Windows Sandbox.
CVE-2026-26268 shows that granting write access to the entire workspace is not enough.
.git is not just another project directory — it is a config region that turns into code execution on the next Git operation.

In the NemoClaw sandbox written for OpenClaw, I noted that filesystem restrictions alone do not stop prompt-injection-style attacks.
Cursor makes this even more concrete: writing to .git became the foothold for a sandbox escape.

AI IDE and coding agent sandboxes need to restrict at least .git/config, .git/hooks/, core.hooksPath, submodule settings, and bare repository handling as a separate category.
Treating them with the same permissions as regular source files means “can write code” escalates to “can execute code on the host.”