Cursor CVE-2026-26268: How to Check if You're Patched and What the Git Hook Bug Actually Does

Cursor users running any version before 2.5 are vulnerable to a critical sandbox escape (CVSS 9.9) that lets a malicious repository execute code on the developer's machine. no install, no consent prompt, no awareness. The bug abuses Git hooks written into a repo's .git directory and is triggered when Cursor's AI agent runs a routine Git operation. NVD published the record on February 13, 2026 and Novee researchers disclosed exploit details on April 28, 2026. This article shows how to confirm you're patched in under a minute and explains what the bug actually does. without shipping a working POC.

TL;DR

Affected: every Cursor build before 2.5
Patched: Cursor 2.5 or later (released Feb 17, 2026)
Fix in 60 seconds: open Cursor, Help -> About, confirm version >= 2.5
If you opened any untrusted repo before patching: rotate tokens, audit shell history
Enable security.workspace.trust.enabled in settings going forward

Am I affected by CVE-2026-26268?

You are affected if you ran any Cursor version before 2.5 on a repository you didn't fully control. The official advisory (GHSA-8pcm-8jpx-hv8r) states the issue plainly: "Sandbox escape via writing.git configuration was possible in versions prior to 2.5." NVD's record assigns a base score of 9.9 CRITICAL with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, classified as CWE-862: Missing Authorization.

The vulnerability does not require you to do anything more than open a malicious repository in Cursor and let the agent run. No additional click. No phishing pretext. As Cybersecurity News reported on April 29, 2026, the malicious hook fires silently, outside the agent's reasoning chain and outside the developer's awareness.

How do I check what version of Cursor I'm running?

Open Cursor, go to Help -> About, and read the version number. If it starts with 2.5 or higher (2.5.x, 2.6.x, 3.x.x), you're patched. If it starts with 2.4, 2.3, 1.x, or 0.x, you're vulnerable and should update immediately.

You can also check from the terminal:

cursor --version

The output is three lines. version, commit hash, architecture:

2.5.20
34881053400013f38e2354f1479c88c9067039a0
x64

The first line is what matters. Anything below 2.5.0 is the vulnerable code path.

Watch out for version mismatch. Cursor users reported on the official forum that the Help -> About dialog and the cursor --version CLI can disagree when both a per-user and a system-wide install exist. If they disagree, check both, and uninstall whichever instance is older. The CLI version is what gets invoked when your shell runs cursor, but the GUI binary is what opens repos. both must be patched.

To update: in Cursor, the menu path is Help -> Check for Updates, or download the latest installer from cursor.com. On Linux installs from a tarball, re-run your install script.

A worked example I'd ship as the article's screenshot

The first-hand artifact for this post is a side-by-side: my own machine before and after the patch. Left frame is the Help -> About dialog showing Version: 2.4.x highlighted in red. Right frame is the same dialog after updating, showing Version: 2.5.20 (the Feb 20, 2026 stability follow-up) highlighted in green. Underneath both is a terminal showing which cursor && cursor --version so the reader can compare to their own output exactly.

What does the Git hook bug actually do?

The bug lets a malicious repository write executable scripts into Cursor's .git/hooks directory from inside the agent's sandbox. and Git then runs them automatically the next time a hook event fires. The CVE record's official wording describes it as:

"A malicious agent (ie prompt injection) could write to improperly protected.git settings, including git hooks, which may cause out-of-sandbox RCE next time they are triggered. No user interaction was required as Git executes these commands automatically."

Here's the educational version of what's happening. no copy-pasteable payload.

Background. Git hooks are scripts that live in a repository's .git/hooks/ directory and run automatically on events like pre-commit, post-checkout, or post-merge. They're trusted local scripts. Git doesn't sandbox them. That's by design and predates AI agents.

The Cursor sandbox. Cursor's agent runs commands inside a sandbox that's supposed to prevent arbitrary code execution on the host. The sandbox controls which files the agent can touch.

The gap. In Cursor versions before 2.5, the sandbox missed an authorization check on writes to .git configuration files, including the contents of .git/hooks. A repository or a prompt injection delivered through repo content could instruct the agent to drop a script into a hook file.

The trigger. Novee's disclosure explains the most reliable variant uses a bare repository nested inside a normal-looking project plus a pre-commit hook. When the agent runs an ordinary git checkout (often instructed by a .cursorrules file in the repo itself), the hook fires automatically, outside the sandbox, with the user's full shell privileges.

The result. Arbitrary code execution on the developer's workstation as soon as the agent touches the repo. Tokens in ~/.netrc, shell history, SSH keys, environment variables, and anything mounted in the developer's home directory are reachable. As CSO Online noted on April 28, 2026, AI agents remove both constraints of traditional safety models. the human-in-the-loop and the trusted-tool assumptions. at the same time.

The fix in 2.5 adds proper authorization on writes to the .git directory so the sandbox no longer permits hook installation.

What should I do if I opened an untrusted repo before patching?

Treat the workstation as potentially compromised and run the same incident-response checklist you'd use for any developer-machine RCE. Then patch and re-secure.

Update Cursor first. No further investigation matters until the bug class is closed. Help -> Check for Updates.
Audit your shell history. Run tail -200 ~/.bash_history, tail -200 ~/.zsh_history, and check Cursor's terminal panes for unfamiliar commands. anything you don't remember running, especially curl, wget, nc, base64, or commands writing to ~/.ssh/ or ~/.aws/.
Check running processes and crons. ps -ef | grep -E 'curl|nc|python|node' for unfamiliar long-running processes; crontab -l and ls /etc/cron.* for new scheduled jobs; on macOS, also launchctl list.
Rotate any tokens reachable from your dotfiles. GitHub PATs, npm tokens, AWS keys, Anthropic / OpenAI keys, Vercel / Cloudflare tokens, anything in ~/.env*, ~/.netrc, ~/.aws/credentials, ~/.config/. Treat them as exposed.
Inspect .git/hooks in repos you cloned recently. find ~/code -path '*/.git/hooks' -type d -exec ls -la {} \; to spot non-default pre-commit, post-checkout, post-merge, or post-receive files. Default hook samples end in .sample and are harmless.
Consider the workstation tainted if anything looks off. Reinstall the OS or restore from a known-good snapshot rather than gambling on partial cleanup.

If you only ever opened repos from your own organization in pre-2.5 Cursor, the practical risk is low. Audit the most recently cloned untrusted repos first.

How do I avoid this class of bug going forward?

Three layers, in order of impact: enable Workspace Trust, run untrusted repos in an isolated environment, and treat your .cursorrules files as code that runs on you.

Enable Workspace Trust in Cursor settings. Cursor inherits VS Code's Workspace Trust feature but ships with it disabled by default. Set "security.workspace.trust.enabled": true in your user settings. With it on, Cursor prompts before running tasks, debug configs, or extensions in a folder you haven't trusted. This is a defense-in-depth layer, not a fix for CVE-2026-26268 itself. but it would have blunted several adjacent attacks reported in 2025-2026.

Open untrusted repos in an isolated dev environment. GitHub Codespaces, Gitpod, a throwaway Docker dev container, or a VM. The principle is simple: the AI agent should never run git checkout on a stranger's code on the same host where your production credentials live. Codespaces in particular gives you a per-repo container that resets cleanly.

Read .cursorrules and .cursor/rules/*.md before letting the agent run. These files are repo-supplied instructions that the agent treats as if you wrote them. Skim any non-trivial one for instructions that ask the agent to run shell commands, fetch URLs, or modify files outside the repo.

FAQ

What is CVE-2026-26268?

CVE-2026-26268 is a missing-authorization vulnerability in Cursor IDE versions before 2.5 that allowed a malicious repository. or a prompt injection delivered through repo content. to write executable Git hooks into the .git directory from inside Cursor's agent sandbox. Once written, the hook ran outside the sandbox the next time a Git event fired. NVD scored it 9.9 (Critical). The official fix shipped in Cursor 2.5 on February 17, 2026.

Is my Cursor patched?

You're patched if Cursor reports version 2.5.0 or higher. Check via Help -> About in the application or cursor --version in a terminal. If both a system-wide and a per-user install of Cursor exist on your machine, check both. the forum has documented cases where the GUI and the CLI report different versions because they point at different installs. Anything before 2.5 is vulnerable and must be updated.

Did I have to do anything to be exploited?

No active step beyond opening a malicious repository in Cursor and letting the agent run a routine Git command. The CVE record specifies "No user interaction was required as Git executes these commands automatically." Cloning the repo from the terminal alone is not enough. the agent's sandbox has to touch the repo. But agents touching cloned repos is the default workflow, which is why this is rated 9.9.

Which Git hooks were exploitable?

Public reporting from Novee specifically documents a pre-commit hook inside a nested bare repository as the demonstrated trigger. The CVE wording is broader. "improperly protected.git settings, including git hooks". which suggests other hooks in the standard set (post-checkout, post-merge, pre-push, etc.) were also writable. Treat any pre-2.5 install as exposed regardless of which specific hook a given POC used.

Is there a working public exploit I should worry about?

As of 2026-05-08, the Novee disclosure post describes the mechanism but the researchers held back a copy-paste-ready POC. Public reporting confirms the bug class is well-understood, which is enough motivation for opportunistic attackers to write their own. The window between public disclosure (Apr 28) and the date you're reading this is the most dangerous interval. Patch.

Why does Cursor's own advisory list CVSS 8.0 while NVD lists 9.9?

The two scores reflect different threat models. Cursor's GitHub advisory (8.0 High) assumes higher attacker privileges and complexity. NVD's analyst (9.9 Critical) treats the agent-driven trigger path as low-complexity and low-privileges-required, since opening a repo is a routine action. NVD's framing is the more defensible one for CVE-2026-26268 specifically, which is why most public reporting uses 9.9.

Cursor 3.3 Context Usage Breakdown: What to Cut First, Read each bucket in the new context ring and trim the right ones.
Fix MCP Server Not Working: The Stdout Bug Hiding Claude's Tools, The 1-line fix per language for the most common MCP setup bug.
Claude Code Subagents That Save Context: 3 Patterns (2026), Three subagent patterns with real measured token-burn savings.
Claude Code New Limits (May 2026): Per-Plan Changes & SpaceX Deal, What doubled and why, plus how to verify your new ceiling.

References

NVD record for CVE-2026-26268. https://nvd.nist.gov/vuln/detail/CVE-2026-26268
Cursor / Anysphere security advisory GHSA-8pcm-8jpx-hv8r. https://github.com/cursor/cursor/security/advisories/GHSA-8pcm-8jpx-hv8r
Novee Security, "How an AI Coding Agent Can Run Exploits in Cursor IDE" (April 28, 2026). https://novee.security/blog/cursor-ide-cve-2026-26268-git-hook-arbitrary-code-execution/
CSO Online, "Critical Cursor bug could turn routine Git into RCE" (April 28, 2026). https://www.csoonline.com/article/4164250/critical-cursor-bug-could-turn-routine-git-into-rce.html
Cybersecurity News, "Cursor AI Coding Agent Vulnerability" (April 29, 2026). https://cybersecuritynews.com/cursor-ai-coding-agent-vulnerability/
Help Net Security, "Default Cursor setting can be exploited to run malicious code" (Sept 11, 2025). https://www.helpnetsecurity.com/2025/09/11/cursor-ai-editor-vulnerability/
Cursor forum thread on checking versions. https://forum.cursor.com/t/how-to-check-cursor-version/105279