Cursor AI's Git Hook RCE Flaw: Patch Now to Secure Your Workflow

Novee Security dropped a CVSS 9.9 on Cursor. Cursor shipped 2.5. That's the rare good news in this advisory.

Most CVEs at this severity end up in the Critical, no patch yet column for weeks. CVE-2026-26268 didn't. Researchers at Novee Security disclosed responsibly, Cursor shipped 2.5 as the fix, and you can apply it today. That — the engine of disclose-and-patch actually turning over — is the headline most security posts bury.

What makes this one worth a closer read isn't the severity score. It's the mechanism: a category of attack that has existed in Git for years became a silent RCE the moment an AI agent started running Git operations for you, autonomously, without a dialog. The patch closes the specific vector. It doesn't close the category. That's the part to think about after you've updated.

What CVE-2026-26268 actually exploits

The bug lives at the intersection of three normal Git primitives that shouldn't combine into a code-execution primitive but did.

Git hooks are shell scripts that fire automatically on Git events — pre-commit, post-checkout, pre-push. They've been a known, awkward attack surface for years. The defense has always been the human-in-the-loop: a developer reads README.md, sees the .git/hooks/post-checkout script, runs rm .git/hooks/* before doing anything, and the threat dies.

Bare repositories are a standard Git data structure: all metadata and object database, no working directory. Crucially, a bare repo can be embedded inside a regular repo. The outer repo looks normal. The inner repo carries the hook.

Cursor's AI agent runs Git operations autonomously as part of its normal workspace-setup behavior. No prompt, no confirmation, no "this repo wants to run a script on your behalf" dialog.

Combine the three and the chain closes itself.

The classification is CWE-862 — Missing Authorization. Cursor's sandbox lacked the write-authorization check on the directory that would have prevented the embedded bare repo's hook from executing outside the sandbox boundary. That's the technical root cause the patch addresses.

The attack chain, in four beats

1. Attacker publishes a repo on GitHub. It looks legitimate — README, code, stars, even a CI badge. Nested inside is a bare repository carrying a pre-commit hook with a payload.
2. Developer clones it and opens it in Cursor. Nothing unusual happens on the filesystem side; the bare repo is just a directory with objects.
3. Cursor's AI agent, as part of normal workspace setup, runs Git operations autonomously. The pre-commit hook fires.
4. The script executes with the full privileges of the user running Cursor. No dialog. No warning. No visible indication anything happened.

Cursor disputed NVD's CVSS 9.9 with their own score of 8.0, arguing prompt injection is a prerequisite. The underlying risk is real regardless of which score you prefer, because the only prerequisite for prompt injection in an AI agent is asking it to do work in a directory under the agent's control — which is the product's entire purpose.

Why the AI agent turns a theory into a weapon

Git hook exploits via malicious repos have been documented for a long time. They never scaled because the attacker needed a human to manually run a Git command against the poisoned directory. There was always a moment — git checkout, git pull, git commit — where the developer saw the hook or got prompted and could intervene.

Cursor's agent removes that moment. As Novee put it, Cursor's agent "fundamentally changes that model." The agent decides autonomously when to run Git operations to fulfill your request, and the developer no longer touches Git directly. The automation that makes AI IDEs fast — do work without round-tripping every command through a human — is the same automation that made this exploit practical at scale.

This is not a Cursor-specific failure mode. It's a class of failure: anywhere an AI agent takes instructions from repository content and acts on them automatically, the same category exists. The patch fixes Cursor's specific authorizations. The category survives every patch.

The patch, the dispute, and what 2.5 actually does

Cursor 2.5 is the patched version. The fix addresses the missing write-authorization check — the sandbox now refuses to let an embedded bare repo's hook execute outside its intended boundary. If you're on 2.5 or later, the specific vector described above does not work against you.

The CVSS dispute is worth noting for what it isn't: nobody involved is arguing the risk is theoretical. The 9.9 vs 8.0 debate is about whether prompt injection should count toward the impact score, which is a calibration argument, not a "you're fine" argument. Apply the patch either way.

# Verify your Cursor version before doing anything else
cursor --version
# or via the application: Help → About

If that returns anything below 2.5, update before you open another repo.

How to actually protect yourself today

This is the part that matters. The source article gives you the patch; the rest is general Git hardening that any senior engineer should be doing on any machine, with or without an AI agent in the loop.

Step 1 — update Cursor.

# If installed via the official package, the updater ships in-app:
#   Cursor → Check for updates → restart
# CLI-managed installs vary by platform; verify against your distro.

Step 2 — make hooks off-by-default for untrusted clones.

The cleanest workaround that doesn't break normal development: rename core.hooksPath to a path you control when working in repos you didn't author.

# Pin the hook path to an empty directory for this clone
git -C ./untrusted-repo config --local core.hooksPath /dev/null

For repos you trust, you can restore default behavior with git config --local --unset core.hooksPath. The article frames the lack of a sandbox authorization check as the bug; this is the workaround before the patch is universal.

Step 3 — inspect before you open.

# What's hiding in .git?
ls -la .git/
ls -la .git/hooks/
find . -name 'hooks' -type d 2>/dev/null

If you see a bare repository embedded as a directory, that's a yellow flag worth a cd away from before you hand the directory to an AI agent.

Step 4 — network discipline. AI agents reach out for tooling. Restrict the agents on machines where cloned-repo exposure is high. Egress allowlists, namespace separation, ephemeral environments — boring infrastructure, but each one stops an arbitrary-code-execution primitive from phoning home with whatever it exfiltrated.

Step 5 — if you suspect compromise, treat it as such. Rotating credentials from a machine that ran an unknown hook isn't paranoia, it's correct procedure. The article is explicit that the hook runs with full terminal privileges — that includes access to every secret in your shell, your SSH agent, and your keychain.

The durable layer underneath the tool churn

The patch closes this CVE. The next category of "AI agent acts autonomously on content from a directory" is already in someone's threat model.

OTF's angle isn't "use Cursor less." Use Cursor 2.5. Use whatever agent shipped its fix. The part that doesn't change when the model does, and doesn't change when the next exploit category lands, is the baseline of what your dev environment will and won't run automatically on your behalf. Reviewed component registries, validated templates, locked-down defaults for what hooks and executables exist in your workspace — these are the things you audit once and that pay off across every agent, every model, every patch cycle that follows.

The incentive to ship fast is real and worth keeping. The discipline to control what's in the directory you hand to the fast thing is the durable part.

Apply the patch. Audit your hooks. Treat every cloned repo as an untrusted input until you've inspected it.