DEV Community

Ramdai Bista
Ramdai Bista

Posted on Originally published at stupidllm.com

Claude Code's Git Worktree Handling Let a Malicious Repo Escape the Sandbox (CVE-2026-55607)

Cloning a repository and running Claude Code against it was enough. No prompt approval, no explicit command — just opening the project.

What the source says

Anthropic's own GitHub Security Advisory (GHSA-7835-87q9-rgvv, CVE-2026-55607) documents a sandbox-escape chain in Claude Code versions ≥2.1.38 and <2.1.163. Security researcher metnew reported it via HackerOne.

The chain has three parts. First, Claude Code allowed creating a git worktree literally named .git, which confuses git about which directory holds the real repository metadata. Second, combined with symlink manipulation, an attacker-controlled worktree path could be steered outside the sandbox boundary entirely. Third, the trigger was git's own fsmonitor mechanism firing automatically during worktree operations — the same class of "git runs a program on your behalf without asking" behavior that made core.fsmonitor a live attack surface elsewhere (more below). A specially crafted repository — one that also carried prompt injection content — used this chain to overwrite a shell initialization file, such as ~/.zshenv, in the user's home directory. The next time the victim opened a shell, the attacker's code ran with the user's own privileges and no sandbox in effect.

Anthropic rated it High under CVSS v4.0 (7.7: AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H) and fixed it in Claude Code 2.1.163. Users on the standard auto-update channel received the fix without any action.

The pattern this fits

This is the second CVE in this database built on git silently executing something during a routine operation. STUPID-2026-0101 (CVE-2026-45033) showed GitHub Copilot CLI running attacker-chosen commands via a nested bare repository's core.fsmonitor setting, triggered by an ordinary git status. Here, a different git mechanism — worktree naming plus fsmonitor triggering — got Claude Code to the same place: code execution the tool never explicitly authorized. Different vendors, different specific bugs, same underlying lesson: an AI coding agent that runs git commands on your behalf inherits every quirk of git's automatic, config-driven behavior, and an untrusted repository can weaponize that behavior before the agent does anything you'd call a "task."

What it doesn't establish

This is a responsibly disclosed and already-patched vulnerability, not a report of a user actually getting compromised. There's no indication in the advisory that this was exploited in the wild — metnew found it, reported it through HackerOne, and Anthropic fixed it before publishing. Reproducibility here means "the advisory's technical description is sufficient to reproduce the chain," which Anthropic itself confirms by publishing the fix; it isn't a claim that anyone outside the disclosure process has independently verified the exploit end to end.

Why it's worth tracking anyway

Sandbox escapes that require nothing but "clone this repo and open your coding agent" are a class of bug users can't easily defend against by being careful — there's no suspicious command to decline. That the trigger is a chain of small git behaviors (worktree naming, symlinks, fsmonitor) rather than one obvious flaw is also why it took a dedicated security researcher to find it, and why the same underlying git surface keeps producing CVEs across different agents.

Top comments (0)