Claude Code脆弱性CVE-2026-55607解説｜git worktree経由のサンドボックス脱出と対策

2026年6月25日、AnthropicはClaude Code脆弱性の新しいセキュリティアドバイザリGHSA-7835-87q9-rgvv（CVE-2026-55607）を公開した。悪意あるリポジトリをcloneしてClaude Codeを走らせるだけで、エージェント自身のworktree操作が踏み台となり、macOSのseatbeltサンドボックスの外でコードが実行されるというものだ。修正版は2.1.163で、npmレジストリ上の公開は2026年6月4日。本記事では、アドバイザリ・報告者の公開write-up・NVD・npmレジストリという一次情報だけを使い、攻撃チェーンの仕組み・深刻度が割れている理由・自分の環境での確認手順を整理する。

この記事はAIコーディングエージェント固有の脆弱性を扱います。開発基盤を狙う攻撃手法と防御ツールの全体像は サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト にまとめています。

30秒でわかるClaude Code脆弱性CVE-2026-55607

何が起きたのか — 4段の連鎖でサンドボックスの外へ

アドバイザリの記述はごく短い。「Claude Codeのworktree処理は.gitという名前のworktreeの作成と、サンドボックスの文脈外にあるworktreeへの移動を許しており、gitディレクトリの混同攻撃を可能にしていた」というものだ。そして「worktree操作の最中にsymlinkの操作とgitのfsmonitorの実行を悪用することで、攻撃者は利用者のホームディレクトリのファイル（.zshenvなど）を上書きでき、seatbeltサンドボックスの制限の外でのコード実行に至る」と続く。

この一文に、性質の異なる4つの要素が畳み込まれている。報告者の公開write-upとあわせて読むと、それぞれが単独では「仕様の範囲」に見えるものの、順番に噛み合ったときだけ境界が破れる構造だと分かる。

1段目：.git という名前のworktree

gitでは、リポジトリのメタデータは.gitという名前の場所に置かれる。ここに同じ名前のworktreeを作れてしまうと、gitが「どこをgitディレクトリとみなすか」の解決が揺らぐ。報告者はこれを「gitディレクトリの混同（git directory confusion）」と呼び、3つある独立したバグの1つ目として挙げている。

なお、素のgitコマンドでgit worktree add .gitとだけ実行すると、手元のgit 2.39.3では fatal: '.git' is not a valid branch name として弾かれる。ただしこれはworktreeのパスからブランチ名を導出する過程で引っかかっているだけで、.gitという名前そのものを拒否しているわけではない。実際、-bでブランチ名を明示し、既存の.gitと衝突しない場所を指定して試すと、gitは.gitという名前のworktreeを問題なく作成する。

つまりgitは.gitという基底名を禁止していない。これを弾くかどうかは、worktreeを作る側のツールの責任範囲にある。2.1.163の修正は、Claude Code側でその受け入れを拒否するものだ。

2段目：worktree保存先のsymlink

次に効くのが、worktreeの保存先がsymlinkだった場合にそれを追ってしまうという挙動だ。write-upによれば、.claude/worktreesをホームディレクトリを指すsymlinkに差し替えることで、以降のworktree作成がプロジェクトの外へ向かう。サンドボックスは「この作業ディレクトリの外に書くな」という境界を敷くが、境界の内側に置かれたsymlinkが外を指していると、書き込み先だけが静かに外へ移動する。

この「symlink追従」は本件に固有の弱点ではない。同じClaude Codeで2026年4月20日に公開されたCVE-2026-39861（2.1.64で修正）も、サンドボックス内のプロセスが作業領域外を指すsymlinkを作れてしまい、非サンドボックスのアプリ側がそれを追って書き込む、という構図だった。AIコーディング支援ツール全般で同じ構造が繰り返し見つかっている点は、GhostApproval・SymJack解説｜AIコーディング支援6種のsymlink承認ハイジャック で整理している。

3段目：core.fsmonitor というコード実行の口

ここが本件のもっとも重要な部分だ。core.fsmonitorはgitの正規の設定項目で、ファイルシステムの変更監視を外部プログラムに任せてgit statusなどを高速化するためのものである。gitの公式ドキュメント（git help config）は、この設定について「フックベースのファイルシステムモニタと同様に、多数のファイルを含む作業ディレクトリでgitのインデックス更新が必要なコマンド（例：git status）を高速化できる」と説明し、真偽値のほかにフックのパス名を指定できると明記している。

つまりcore.fsmonitorは、指定されたコマンドがgit statusのような日常的な操作のたびに起動する設定である。これは意図された機能であり、gitのバグではない。しかし攻撃者が用意したリポジトリのgit設定にこの項目が仕込まれていれば、エージェントがworktree操作の過程で何気なくgit statusを走らせた瞬間に、攻撃者のコマンドが動く。報告者はこれを「gitのcore.fsmonitorは、ありふれたコマンドで発火するコード実行のシンクだ」と表現している。

Gitの正規機能がエージェント経由で攻撃の起点になる構図は他ツールでも観測されており、Cursorの事例は Cursor IDE脆弱性CVE-2026-26268解説｜Gitフックで任意コード実行、影響バージョンと対策 にまとめている。

4段目：~/.zshenv はサンドボックスより先に読まれる

最終段は、実行したいコードを~/.zshenvに書き込むことだ。ここで効くのがzshの起動順序である。zshは起動時に~/.zshenvを最初期に読み込む。write-upは、macOSではこのファイルが「seatbeltプロファイルが適用される前に」読まれると指摘している。

この一点が、本件を「ファイル書き込み」ではなく「サンドボックス脱出」にしている。サンドボックスは、その中で起動されるコマンドの権限を絞る仕組みだ。しかし、シェルそのものが立ち上がる過程で読む初期化ファイルを書き換えられてしまえば、制限が掛かる前に攻撃者のコードが評価される。報告者はこの点を「シェルが制限の適用前に攻撃者の~/.zshenvを読み込むなら、ペイロードのコマンドをサンドボックス化しても意味がない」と要約している。

報告者は独立した3つのバグとして、①.gitをworktree名として受け入れたこと、②worktree作成時にsymlinkを追ったこと、③ホームディレクトリへの書き込みを明示的な承認なしに許したこと、を挙げている。2.1.163が塞いだのは①である。

なぜ「サンドボックス有効」でも防げなかったのか

本件でもっとも誤解されやすいのが、この点だ。報告者は、サンドボックスを有効にし、bashの自動承認を無効にした最も制限の強い設定でも成立したと述べている。

理由は前節のとおり、最終段がシェルの初期化ファイルだからである。サンドボックスは「実行されるコマンド」に対する制限であり、「シェルが起動する前に読むファイル」は制限の対象より前段にある。順序として先にあるものは、後から掛かる制限では守れない。

この構造は、設定ファイルを書き換えられると防御が無効化されるという点で、同じClaude Codeで報告されたClaude CodeのMCP通信ハイジャックでOAuthトークンが窃取される攻撃｜検知・対応・防御の手順 と発想が近い。ただし両者は別の事象である。MCP通信ハイジャックはCVEが採番されずAnthropicが「設計上の挙動・対象外」と分類しパッチも出していないのに対し、本件はCVEが採番され2.1.163で修正されている。「設定ファイルが権限の実体を握っている」という共通の教訓はあるが、対応の要否がまったく違う。

⚡ 自分の環境を確認する

最初にやるべきことは、動いているClaude Codeのバージョンをすべて数えることだ。ここには実務上の落とし穴がある。

claude --versionは、PATHの先頭で見つかった1つの実体のバージョンしか表示しない。Claude Codeはネイティブインストーラ経由とnpmグローバル経由の両方で導入でき、両者は別々の場所に入る。実際、本記事の検証環境では次の状態になっていた。claude --versionは2.1.220（修正済み）を返すが、npmグローバル側には2.1.87が残っており、これは影響範囲の2.1.38以上2.1.163未満に該当する。PATHの順序が違うシェルやCIのコンテキストでは、古い方が動きうる。

# 1. claude の実体をすべて列挙し、それぞれのバージョンを確認する
which -a claude
for p in $(which -a claude); do printf '%s -> ' "$p"; "$p" --version; done

# 2. npm グローバル導入分を個別に確認する
npm ls -g @anthropic-ai/claude-code --depth=0

# 3. CI・コンテナに固定バージョンが残っていないか探す
grep -rn "@anthropic-ai/claude-code@2\.1\." . --include=Dockerfile --include="*.yml" --include="*.yaml" --include="package.json" 2>/dev/null

2の結果や3で見つかった固定指定が2.1.38以上2.1.163未満なら、その経路は影響範囲内である。

次に、影響期間中に素性の分からないリポジトリをエージェントに解析させた覚えがある場合の痕跡確認を挙げる。断定的な侵害判定に使えるものではないが、連鎖の各段が残す形跡を見る位置づけだ。

# シェル初期化ファイルに見覚えのない追記がないか（最終段の書き込み先）
ls -la ~/.zshenv ~/.zshrc ~/.bashrc ~/.profile 2>/dev/null
tail -n 20 ~/.zshenv 2>/dev/null

# worktree の保存先が symlink にすり替わっていないか（2段目）
ls -la .claude/worktrees 2>/dev/null
find . -maxdepth 4 -type l -name "worktrees" 2>/dev/null

# リポジトリの git 設定に見慣れない fsmonitor が入っていないか（3段目）
git config --get core.fsmonitor
git config --list --show-origin | grep -i fsmonitor

git config --get core.fsmonitorが何も返さなければ設定されていない。値が返る場合は、それが自分で入れた高速化設定（trueやチームで合意したツールのパス）なのかを確認する。身に覚えのないパスが入っていれば要調査である。

深刻度が 8.8 と 7.7 に割れている理由

本件を調べると、参照先によって深刻度の数字が違う。これは矛盾ではなく、採点しているバージョンと組織が違うためである。

差を生んでいるのは主にAttack Requirements（AT）という指標だ。CVSS 4.0の仕様書は、AT:Pを「攻撃の成功が、攻撃を可能にする特定の配備・実行条件の存在に依存する」場合と定義している。本件は「プロンプトインジェクションを含む悪意あるリポジトリをcloneして、そこでエージェントを走らせる」という条件が必要なので、4.0ではここで減点される。一方CVSS 3.1にはこの軸自体が存在せず、条件付きであることを減点に反映できない。

もう1つの差は利用者の関与の表現だ。CVSS 4.0はUser Interactionを None / Passive / Active の3段階で区別し、Passiveを「対象利用者による限定的な関与が必要で、その関与は意図せざるものであり、利用者が保護機構を能動的に破ることを要求しない」と定義する。3.1はRequired / Noneの2値しかないため、同じ状況をUI:Rとしか書けない。

実務上の結論はシンプルで、どちらもHighであり、低い方の数字を根拠に対応を先送りする理由にはならない。むしろUI:P（受動的）という評価は、「利用者が特別に危険な操作をしたわけではない」という意味であり、日常的なclone→解析の流れで踏みうることを示している。

Claude Code脆弱性の影響範囲と前提条件

影響バージョンの下限2.1.38がnpmに公開されたのは2026年2月10日、修正版2.1.163の公開は6月4日である。両者の差は114日で、この間に導入・固定されたバージョンは影響範囲に入る。標準の自動更新を使っている環境はすでに修正版へ到達しているが、固定バージョンを使うCI・コンテナ・オフライン環境が残存リスクの中心になる。

前提条件は軽くない一方で、日常操作から遠いわけでもない。「知らないリポジトリをcloneしてエージェントに読ませる」はAIコーディングの典型的な使い方であり、CLAUDE.mdのようなエージェント向け指示ファイルが攻撃者の制御下にある点が本件の肝である。

worktree・symlinkは繰り返し塞がれている

本件を単発の不具合として見ると全体像を見誤る。GitHub Security Advisories APIでanthropics/claude-codeのアドバイザリを取得し、公開日と概要で並べると、同じ系統の攻撃面が2026年に繰り返し塞がれていることが分かる。

パス解決・symlink・信頼境界という同じ土俵で、報告者も異なるまま複数回の修正が重ねられている。これは製品が特別に脆いことを意味するのではなく、エージェントに与えたツールがそのまま攻撃面になるという構造的な性質を示している。報告者の言葉を借りれば「AIコーディングエージェントのツールは攻撃面である」ということだ。

エージェントがgit worktreeやgit statusを自律的に実行できるということは、gitの設定に仕込まれた副作用も自律的に踏むということでもある。エージェントに許可するコマンドを考えるとき、そのコマンドが読む設定ファイルを誰が書けるのかまで含めて見る必要がある。

対策と運用

やることは1つで、2.1.163以降へ更新する。追加の設定変更は不要である。

# ネイティブインストーラ経由の場合（自動更新が有効なら通常は到達済み）
claude update

# npm グローバル経由の場合
npm install -g @anthropic-ai/claude-code@latest

更新後に、前掲のwhich -a claudeですべての実体が2.1.163以降になったことを確認する。片方だけ更新して安心するのが典型的な失敗である。

運用面では、次の3点が本件から引ける実務的な示唆になる。

・素性の分からないリポジトリは、まずエージェントを外して開く。CLAUDE.mdのようなエージェント向け指示ファイルは、攻撃者が最初に置く場所である
・固定バージョンの棚卸しを定期化する。自動更新が効かないCI・コンテナ・オフライン環境が、この種のCVEでは最後まで残る
・シェル初期化ファイルを変更検知の対象に含める。~/.zshenvはサンドボックスより前に読まれるため、どんなサンドボックス設定を入れてもこのファイルの保護にはならない

よくある誤解

・「サンドボックスを有効にしていたから大丈夫」ではない。報告者は最も制限の強い設定でも成立したと述べている。最終段がseatbelt適用前に読まれるファイルだからである
・「7.7だから8.8より軽い」ではない。両者は別バージョンのCVSSによる採点で、どちらもHighである
・「claude --versionが修正版だから安全」ではない。PATHの先頭1つしか見えず、別経路で入った古い実体は映らない
・「gitのバグ」ではない。core.fsmonitorが指定コマンドを実行するのは公式に文書化された正規機能であり、問題はエージェントが攻撃者の制御下にあるgit設定を踏む経路にあった
・「CVEが出たばかりの新しい話」ではない。GHSA公開は2026年6月25日、修正版2.1.163の公開はさらに前の6月4日である。速報として身構えるより、固定バージョンが残っていないかの棚卸しに時間を使うほうが実益が大きい

参照ソース（一次ソース優先）

・GHSA-7835-87q9-rgvv — Sandbox Escape via Git Worktree Path Confusion Allows Unsandboxed Code Execution（Anthropic公式アドバイザリ。影響範囲・修正版・機構の記述）
・Metnew/write-ups — claude-code-worktree-sandbox-escape（報告者による公開write-up。開示タイムライン・3つのバグの整理・報告者自身の主張）
・NVD — CVE-2026-55607（CVSS 3.1での採点8.8・CWE分類・登録日）
・CVSS v4.0 Specification Document — FIRST（Attack Requirements・User Interactionの定義）
・GitHub Security Advisories — anthropics/claude-code（同系統アドバイザリの公開日・概要の集計元）
・npm registry — @anthropic-ai/claude-code（2.1.38・2.1.163の公開日）