al-ice.ai

A Malicious Repository Could Drive Claude Code Out of Its Sandbox — CVE-2026-55607

AI CVEs by al-ice.ai Editorial

A malicious repository could turn Claude Code’s own Git worktree operations into a path out of its macOS seatbelt sandbox. The exploit chained instructions planted in repository content with a worktree named .git, symlink redirection, attacker-controlled Git configuration, and a shell startup file. The result was unsandboxed host code execution even when the proof of concept enabled the sandbox and disabled automatic approval for sandboxed Bash commands.

CVE-2026-55607 affects @anthropic-ai/claude-code from version 2.1.38 up to, but not including, 2.1.163. Anthropic fixed the issue in 2.1.163, released June 4. The vendor advisory rates it High; the CVE record assigns 7.7 under CVSS 4.0, while NVD separately scores it 8.8 under CVSS 3.1. Standard auto-update users received the fix automatically, but managed or manually updated installations should verify their deployed version rather than assume the update landed.

The disclosure is especially useful because it crosses three boundaries often evaluated in isolation: whether repository text can steer an agent, whether an agent’s structured tools are safe, and whether a sandbox begins early enough in process startup. Each control appeared restrictive on its own. Their composition still gave attacker-authored instructions a route to the user’s home directory and then to execution before sandbox enforcement.

The repository was both prompt and exploit state

Reliable exploitation required the user to clone a malicious repository and run Claude Code against it. The researcher’s proof of concept placed a procedural prompt injection in CLAUDE.md, directing the agent through a precise sequence of enter, exit, create, and status operations. It also shaped the repository root to resemble a valid Git directory, including attacker-controlled HEAD, objects, refs, and configuration.

The critical naming collision was a worktree called .git. Claude Code accepted that name, allowing the generated worktree path to collide with the directory Git normally treats as repository metadata. Once Git resolved the attacker-built layout as its gitdir, routine worktree operations and git status trusted the malicious configuration.

That configuration set core.fsmonitor to an attacker-controlled command. Git’s fsmonitor facility can execute a hook while answering ordinary status queries, so the exploit did not need to persuade the user to approve an obviously hostile shell command. Claude Code’s sanctioned worktree flow supplied the Git invocations that advanced the chain.

Symlinks moved the worktree boundary into the home directory

The staged fsmonitor payload replaced Claude Code’s worktree directory with a symlink to the user’s home directory. Subsequent worktree creation followed that redirection, and crafted worktree metadata made the home directory appear as a registered location that the agent could enter. The chain then gained a file-write primitive outside the project sandbox.

On the demonstrated macOS path, the payload appended commands to ~/.zshenv. Claude Code launched Bash-tool payloads through zsh, and the shell read that startup file before applying the seatbelt profile to the requested command. The next otherwise harmless shell invocation therefore executed the planted startup code without the sandbox restriction.

The public proof of concept used Calculator as a visible marker; the security impact is arbitrary code execution with the desktop user’s authority. Anthropic’s advisory also describes home-directory overwrite and code execution outside seatbelt restrictions. The exact .zshenv transition is macOS-oriented, but the underlying ability to redirect agent-managed writes into $HOME is the broader security failure. Linux and WSL deployments should not treat the macOS demonstration as evidence that vulnerable versions are safe.

Prompt injection was a precondition, not the entire vulnerability

This was not a single-turn “ignore previous instructions” bypass. The attacker needed a prepared repository, prompt-injected agent behavior, and a multi-stage tool sequence to complete in order. The CVE’s CVSS 4.0 vector records attack requirements as present, and CISA’s enrichment assessed the issue as not automatable with no known exploitation at the time of its June 29 update.

Those constraints lower opportunistic exploitability, but they do not restore the intended security boundary. Repository content is routinely untrusted in coding-agent workflows: pull requests, test fixtures, issue reproductions, and third-party projects all place attacker-influenceable text and files in front of the agent. A sandbox is specifically valuable when the model follows the wrong instruction. Treating prompt injection as an excuse for a filesystem escape would invert the control’s purpose.

The important design lesson is that structured agent tools are privileged interpreters. CreateWorktree may look safer than arbitrary Bash, yet it combines pathname handling, symlink resolution, Git configuration, hooks, and process startup. Its security contract must cover all of those downstream semantics, not only the arguments visible to the model.

Defensive engineering response

  • Upgrade Claude Code to 2.1.163 or later. Standard auto-update should have delivered the patch, but confirm with the installed binary on every developer workstation, CI runner, and managed image. Prefer a current supported release rather than stopping at the minimum fixed build.
  • Enforce a minimum version centrally. Claude Code 2.1.163 added a requiredMinimumVersion managed setting. Organizations can use that control to refuse startup below an approved baseline instead of depending on individual update behavior.
  • Do not run vulnerable agents on untrusted repositories. If an immediate upgrade is impossible, keep Claude Code away from external forks, pull-request checkouts, downloaded examples, and repositories containing contributor-controlled agent instructions. Disabling worktree use reduces this specific path but is not a substitute for patching.
  • Inspect host persistence and Git execution surfaces. Review ~/.zshenv and other shell startup files for unexplained changes; examine .claude/worktrees for symlinks or worktrees outside expected roots; and look for suspicious core.fsmonitor, hooks, credential helpers, or command-bearing Git configuration in repositories the agent opened.
  • Put the sandbox around process initialization. A policy applied after the shell reads user-controlled startup files leaves a pre-sandbox execution window. Spawn non-interactive commands with startup-file loading disabled where possible, sanitize relevant environment variables, and establish OS confinement before launching any interpreter.
  • Validate paths by resolved identity. Reject reserved names such as .git, resolve symlinks before authorization, require the final worktree path to remain beneath an approved root, and re-check after filesystem operations to reduce time-of-check/time-of-use gaps.

CVE-2026-55607 is a concrete example of why “read-only model permissions” and “sandbox enabled” are not sufficient security outcomes. The model never needed a direct permission to edit the user’s home directory. It only needed access to a trusted helper whose downstream Git and shell semantics could be composed into that write. Agent security reviews should therefore trace every tool from natural-language input to its final operating-system effects—including configuration files, symlinks, hooks, and interpreter startup—not stop at the tool-call schema.

Sources: