CVE-2026-26268: Cursor's agent turns a git checkout into code execution

What is this?

CVE-2026-26268 is a high-severity arbitrary-code-execution flaw in the AI-powered IDE Cursor, affecting every version before 2.5. Cursor published the advisory (GHSA-8pcm-8jpx-hv8r) in February 2026, and Novee Security researcher Assaf Levkovich detailed the mechanics publicly on April 28, 2026 (covered by The Hacker News on April 30). The flaw carries a CVSS score of 8.1; the vendor classed it as a sandbox escape via .git configuration. The disclosure was coordinated with Cursor and the fix shipped before publication.

The bug is not in Cursor’s own model logic. It is a feature interaction in Git that becomes exploitable the moment an AI agent starts running Git commands autonomously inside a repository it does not control. The payoff: attacker code runs directly on the developer’s workstation, with no approval dialog.

How it works

Two legitimate Git features combine to create the condition:

• Git hooks are scripts that run automatically on events like post-checkout or pre-commit. They live in a repository’s .git directory, which is not part of the tracked, reviewable file tree.
• Bare repositories contain only the .git data with no working directory. One can be embedded inside an ordinary repository.

An attacker publishes a normal-looking public repository that hides a bare repository carrying a malicious hook. The trigger is the agent’s autonomy. Per the disclosed sequence:

1. A developer clones the public repo and opens it in Cursor.
2. They ask something innocuous — “explain the codebase”.
3. Cursor’s agent reads the repo’s AGENTS.md / Cursor Rules, which instruct it to navigate into the embedded bare repository and run a git checkout.
4. The checkout fires the planted hook → code execution.

No payload is reproduced here, and none is needed to grasp the lesson. The user authorised “explain the codebase”, not “execute an attacker’s shell script”. But the agent ran git checkout to satisfy the request, and the hook executed outside the agent’s reasoning chain and outside the user’s field of view. The agent never reported running a script because, as far as it knew, it ran a routine Git command.

This is the same structural pattern behind sibling disclosures in coding agents: an instruction file in untrusted content (AGENTS.md supply-chain injection) steers the agent, and an auto-approved or invisible action turns that steer into execution — see SymJack’s lying approval prompt and Cursor’s allowlist auto-approval bypass.

Why it matters

A developer machine is a production-equivalent target. It holds source code, SSH keys, cloud credentials, and signing tokens, and it sits inside the corporate network. Arbitrary code execution there is frequently the first step toward broader compromise or a supply-chain pivot.

What makes this class newly dangerous is the collapse of the required-action constraint. Classic “client-side” attacks on developers needed a deliberate mistake: open a malicious file, run a script, click a link. That need for a human action was itself a brake on exploitability. An autonomous agent removes the brake. Cloning a public repository and asking a question is now enough to reach code execution — and AI-assisted workflows are automating exactly that loop at scale.

It also widens the audit surface. When a security team reviews an AI coding tool, the tool’s own code is only part of the picture. The content the agent operates on — repositories, AGENTS.md, Cursor Rules, hooks in a cloned tree — is now part of the attack surface, and the execution environment the agent drives (Git, here) is directly relevant to the tool’s security.

Defenses

Cursor owns the specific fix; defenders own the surrounding blast radius and the next variant of the pattern.

• Update Cursor to 2.5 or later. This is the vendor remediation for CVE-2026-26268. Track coding-agent advisories on your normal patch cadence.
• Disable or sandbox Git hooks for untrusted repos. Set core.hooksPath to an empty, controlled directory when cloning code from outside your trust boundary, and inspect any embedded .git directories before letting an agent operate. git clone --no-checkout plus a manual review avoids triggering checkout-time hooks.
• Treat agent instruction files as untrusted input. AGENTS.md, Cursor Rules, README directives and similar in a cloned repo are attacker-controllable. Do not let them silently authorise filesystem navigation or Git operations against paths you did not choose.
• Run coding agents in a sandbox. Containers, VMs or restricted users limit what a fired hook can reach — credentials, network, and the rest of the filesystem. Keep secrets out of the environment the agent runs in.
• Make autonomous actions visible and reviewable. Prefer configurations that surface the concrete commands an agent executes (especially Git and shell operations) over auto-approval. Human-on-the-loop oversight of what ran is the control whose absence this CVE exploited.
• Open untrusted repositories in a throwaway environment first. Clone, review, and only then bring code into the environment where your agent has real privileges.

Status

Item	Detail
CVE	CVE-2026-26268
Component	Cursor IDE (AI agent + Git interaction)
Class	Sandbox escape via .git config → arbitrary code execution
CVSS	8.1 (high)
Affected	Cursor < 2.5
Fixed in	Cursor 2.5
Vendor advisory	Feb 2026 (GHSA-8pcm-8jpx-hv8r)
Public disclosure	Apr 28, 2026 (Novee Security)
Disclosure	Coordinated; patched before publication

The right framing is not “a Cursor bug”. It is that autonomy converts long-known, benign environment features into one-click attack paths. Git hooks and bare repositories have behaved this way for years; what changed is an agent willing to run git checkout on an untrusted repo without a human watching. Every AI coding tool that autonomously drives a powerful local environment inherits the same shape, and the durable defense is to assume the content the agent touches is hostile and to keep a human able to see what the agent actually executed.