Cursor Sandbox Escape via Git Hooks: Prompt Injection Meets Git Automation (CVE-2026-26268)
Cursor's AI agent can be told to write files. Nothing in versions before 2.5 prevented it from writing to <code>.git/hooks/</code>. An attacker who can inject a prompt into the agent's context, via a malicious repository, a crafted issue body, or a poisoned tool response, can plant a hook script that Git will execute automatically on the next commit, push, or checkout. The sandbox breaks the moment the developer runs a routine Git operation. No second prompt required.
What happened
Cursor operates its AI agent inside a sandboxed execution environment. The intent is that the agent can run commands, but only commands the user has approved, and only within the scope of the project being worked on. CVE-2026-26268, disclosed publicly on April 28, 2026 by Novee researchers, demonstrates that the sandbox did not restrict write access to .git/hooks/.
Git hooks are executable scripts that Git runs automatically in response to repository events: pre-commit fires before a commit is recorded, post-checkout fires after a branch switch, pre-push fires before a remote push. Any file placed in .git/hooks/ with executable permissions will be invoked by Git without any additional user confirmation.
The attack uses indirect prompt injection to deliver the payload. An attacker plants malicious instructions in content the Cursor agent will read, a cloned repository's README, an issue body fetched via the GitHub MCP server, or a tool description returned by a remote MCP server. Those instructions direct the agent to write an attacker-controlled script to .git/hooks/pre-commit. The agent complies, because nothing in Cursor prior to 2.5 classified that write as out-of-scope. The next time the developer runs git commit, the script executes outside the sandbox with the developer's full OS privileges.
Anysphere fixed the issue in Cursor 2.5 by restricting write access to .git/ configuration paths within the sandboxed environment. The fix was completed in February 2026 under coordinated disclosure; public details were released April 28, 2026 to allow the community to patch before full attack analysis became public.
The PolicyLayer angle
The exploit exploits a three-part chain: the agent reads untrusted content, the agent can write to any project path, and Git executes hook scripts automatically. A policy layer enforcing the principle of least privilege on file writes breaks the chain at the second step without requiring any change to the agent's reasoning capability.
The specific controls: maintain a path-based allowlist for agent file writes that explicitly excludes .git/ and its subdirectories; require separate, out-of-band approval for any write that targets a file or directory with elevated execution semantics (hook directories, shell startup files, CI configuration); and flag any agent session that has consumed external content before permitting writes to project configuration paths. Cursor's fix in 2.5 implements the first of these at the sandbox layer. The second and third are policy-layer controls that apply regardless of IDE version and protect against the next variant of the same attack class.
The pattern will repeat. Any AI coding agent that can write files, runs in a project directory, and operates on content from untrusted sources has a version of this attack waiting for it. The distinguishing question is not which hook directory is unprotected; it is whether the agent's write scope is governed by an explicit, reviewable allowlist or by the absence of an explicit deny.
Mitigations
Upgrade Cursor to version 2.5 or later. As an immediate workaround before patching, disable Git hooks globally with git config --global core.hooksPath /dev/null and make existing hook directories read-only. Audit .git/hooks/ in any repository that has been opened in Cursor running a version before 2.5, particularly if that repository was cloned from a public source or has had external contributors. Treat any unexpected executable files in hook directories as a potential indicator of compromise.
FAQs
No. Any prompt injection path into the Cursor agent works. The attacker needs to deliver malicious instructions that the agent will act on. That could come from a crafted README in a cloned repository, an issue body fetched via a GitHub MCP tool, a poisoned tool description returned by a remote MCP server, or any other content the agent reads from an untrusted source. The MCP connection is one of several possible delivery mechanisms.
Yes. Once the hook script is written, it re-executes on every qualifying Git operation until it is removed or the hook directory is cleaned up. The attacker does not need continued access to the injection vector after the initial write. A single successful prompt injection into one Cursor session can produce persistent code execution across the entire lifetime of that repository checkout.
Standard coordinated disclosure practice. Novee reported the issue to Anysphere, the fix was developed and shipped in Cursor 2.5 in February 2026, and public details were withheld until April 28, 2026 to give the community time to update before the attack chain was fully documented. The CVE was reserved in February and published when coordinated disclosure completed.