リポジトリに自身の信頼性を投票させてはならない

2026年4月24日、AnthropicはGHSA-q5hj-mxqh-vv77を公開しました。これはCVSS 7.7のClaude Code信頼ダイアログバイパスです。その37日前の3月18日、同じプロジェクトが同じCVSSスコアでGHSA-mmgp-wc2j-qcv7を公開していました。同じ6週間という期間内に、同一のエージェントランタイムで信頼ダイアログバイパスが2件発生したのは、偶然ではありません。¹²

共通する形こそが教訓です。3月のバグでは、プロジェクト管理下の.claude/settings.jsonがワークスペース信頼チェックよりも先に読み込まれ、そのファイル内のbypassPermissions権限モードが、いとも簡単にゲートを通過させてしまいました。² 4月のバグでは、悪意のあるリポジトリが.git/内に細工されたcommondirファイルを同梱し、信頼評価器がポインタを辿ってユーザーがすでに信頼しているディレクトリへとアクセスし、ワークスペースがダイアログを表示することなく信頼を継承してしまいました。¹

まだ誰も開いていないリポジトリ内のたった2行のテキストが、ワークスペースを信頼済みに票決できてしまう状態でした。 リポジトリが同梱するプロジェクトレベルのサーフェス（フック、MCPサーバー設定、スキル、サブエージェント）は、その票決に対して解決され得ます。セッション開始時に積極的に行われるか、呼び出し時に遅延的に行われるかの違いだけです。エージェントランタイムにおける下流の防御策は、それらが存在する前にランタイムが下す決定にゲートされているのです。

TL;DR

• 37日間で発生したClaude Code信頼ダイアログバイパスCVE 2件は、リポジトリ管理下のバイトがワークスペースの信頼に影響を与えると何が壊れるかを示しています。
• ユーザー側の即時的な修正は、2.1.84以降にアップグレードし、~/.claude.json内の信頼済みパスを絞り込み、~/Projectsのような広範な親パスへの信頼を避けることです。
• 構造的な修正はロード順序の不変条件です。ワークスペースのパスが明示的に信頼されるまで、ワークスペースのバイトを一切解釈しないことです。

2件のアドバイザリが実際にパッチした内容

ドキュメントと照らし合わせてパッチを読むと、ロード順序の欠陥が見えてきます。修正版では、信頼評価器が参照を許可されるバイトの順序が変更されています。

3月のアドバイザリは、Claude Codeがワークスペース信頼を解決する前にプロジェクト設定を解決していたことを記述しています。2.1.53での修正はその順序を逆転させ、信頼チェックがユーザーの判断を経る前にワークスペース内の.claude/settings.jsonを読み込まないようにしました。² 4月のアドバイザリは、信頼評価器がワークスペースパス自体を解決する際に、リポジトリの.git/ディレクトリ内のcommondirファイルを辿っていたことを記述しています。2.1.84での修正は、信頼評価中に評価器がリポジトリ管理下のcommondirの内容を尊重しないようにしました。¹ 両方のパッチは同じ不変条件を回復させています。信頼の決定は、評価対象のワークスペース内に存在するバイトを参照してはなりません。

CVEの分類も同じ診断を指し示しています。3月のバグはCWE-807、Reliance on Untrusted Inputs in a Security Decision（セキュリティ決定における信頼できない入力への依存）として登録されています。³ 4月のバグはCWE-20とCWE-77、Improper Input Validation（不適切な入力検証）とImproper Neutralization of Special Elements（特殊要素の不適切な無効化）として登録されています。commondirの解決がリポジトリ管理下のバイトを権威あるものとして扱ってしまったためです。¹ 異なるCWEですが、壊れている前提は同じです。セキュリティゲートが、自らがゲートしている対象の成果物から読み込んでいるのです。

信頼前のサーフェスは、設定リファレンスが示唆するよりも広い

Claude Codeは、信頼ゲートの背後に留まらなければならない一連のプロジェクト管理下のセッション開始サーフェスをドキュメント化しています。このクラスの2つのCVEは、それらのいずれかが信頼決定そのものに入り込むと不変条件が破綻することを証明しました。サーフェスは、信頼分析が分けて扱う必要のある2つのスコープに分かれます。クローンされたリポジトリと共に同梱されるバイトと、ユーザーがコミットせずにワークスペースに追加するバイトです。⁴⁵⁶⁷

リポジトリにコミットされるサーフェス（git cloneで同梱される）。 これらはサプライチェーンのサーフェスです。このグループにあるものは、攻撃者が悪意のあるリポジトリを作成する際にコントロールできるものです。

ワークスペースローカルのサーフェス（デフォルトではコミットされない）。 これらはサプライチェーン経由でワークスペースに乗ってくるものではありません。ローカルユーザーが作成したときに現れるものです。それでもワークスペースパス内に存在するため、信頼ゲートはパスが承認されるまで、これらを信頼できないものとして扱う必要があります。

フックは別ファイルではなく.claude/settings.jsonの中に存在します。4月のアドバイザリは、攻撃者がそのキーに直接データを入れる手口を記述しています。¹⁶ 4月のバグはまた、Claude Codeの設定リファレンスにまったく含まれていないサーフェスを露呈させました。git内部のcommondirという名前のファイルで、ワークツリーを親リポジトリへと解決するものです。⁸ 細工されたcommondirレイアウトを同梱する悪意のあるリポジトリは、信頼評価中にClaude Codeがそのポインタを辿ったときに、ターゲットパスの信頼を継承してしまいます。git内部のサーフェスがプロジェクト設定サーフェスのカウントを破綻させたことが、本当の教訓です。分類は閉じていないのです。攻撃面はダイアログが発火する前にどのバイトが読み込まれるかによって定義され、パス解決や設定に影響を与え得るものはすべて対象となります。

このパターンは、MCPサーバーは新たな攻撃面であるが異なる高度で名付けたものと同じです。⁹ MCPサーバーは、エコシステムがその影響に追いつく前に、ツールプロバイダのサーフェスを爆発的に拡大させました。信頼ダイアログバイパスは、それを1階層下げた同じ形なのです。リポジトリがエージェントを事前設定できるあらゆる便利機能は、上記の分類表に新しい行を追加します。すべての行が、このクラスの次なるCVE候補となります。

キャビネットの裏側：賢いダイアログではなく、ロード順序の不変条件

ポール・ジョブズはスティーブに、キャビネットの裏側も表面と同じ気遣いに値することを教えました。¹⁰ キャビネットの比喩はここでは装飾ではありません。修正の背骨そのものです。

信頼ダイアログはキャビネットの裏側です。ユーザーにはロード順序が見えません。彼らに見えるのはダイアログだけで、Trustをクリックし、そのクリックまでワークスペース内のあらゆるバイトは不活性であると想定します。実装はその想定を勝ち取らなければなりません。それができないとき、その想定そのものが攻撃面になります。

ロード順序こそが、その想定が勝ち取られているかを決める不変条件です。2件のアドバイザリと公開されているClaude Code設定ドキュメントから示唆される最小限のモデルは、おおよそ次のとおりです。²¹⁶

1. ~/.claude/settings.jsonからユーザー設定を読み込む。
2. ~/.claude/settings.local.jsonからユーザー設定を読み込む。
3. 現在のワークスペースパスが信頼されているかを評価する。
4. されていなければダイアログを表示。ユーザーがTrustをクリックすればパスを永続化する。
5. リポジトリ内のプロジェクトスコープの.claude/settings.jsonを読み込む。
6. プロジェクトスコープの.claude/settings.local.jsonを読み込む。
7. マージされた設定からフック、MCPサーバー、スキル、サブエージェントを解決する。
8. SessionStartフックを実行する。

アドバイザリはすべてのステップを正確にドキュメント化しているわけではなく、設定マージに対するスキル、サブエージェント、MCPの配置はユーザーには見えない実装の詳細です。アドバイザリが確立しているのは、ステップ3における境界です。ステップ3より前に解決されるものは信頼できる入力ゾーンに含まれます。ステップ3以降で解決されるものは、ワークスペースのバイトを参照してはなりません。3月のバグはステップ3と5を入れ替えてしまいました。プロジェクト設定が先に解決され、それらの設定が指定する権限モード（bypassPermissions）がステップ3の信頼チェックを簡単に通過させたのです。² 4月のバグは攻撃をステップ3そのものに移しました。ワークスペースパスの解決がリポジトリ管理下のcommondirファイルを参照し、偽造によって信頼チェックが攻撃者の選んだ信頼済みパスに対して解決されてしまったのです。¹ いずれにせよ、ステップ7や8に到達するときには、ワークスペースはすでに信頼済みであり、すべてのプロジェクトレベルのサーフェスがその票決に対してロードされてしまうのです。

キャビネットの裏側が要求するルールは1文です。ユーザーがワークスペースパスを明示的に信頼するまで、ワークスペース内のバイトを一切解釈しないこと。 .claude/settings.jsonもダメ。commondirもダメ。CLAUDE.mdもダメ。ファイル名のリストもダメ。フックファイルもダメ。MCPサーバー設定もダメ。ワークスペース内に存在するものは、信頼を判断するコードが目を向けてはならないのです。

Visual Studio Codeは2021年5月、Workspace Trust（リリース1.57）としてこの修正を出荷しました。コアのフォルダ信頼クラスは機能の出荷以来、公開されたバイパスを生んでいません。ただし、信頼済みドメインや拡張機能の動作に関する周辺の問題は引き続き表面化しています。¹¹¹² 3月のアドバイザリで参照されている修正であるバージョン2.1.53は、ステップ3と5を並べ替えることでClaude Code版の不変条件を実現しました。² 4月のアドバイザリで参照されている修正であるバージョン2.1.84は、信頼評価中にリポジトリ管理下のcommondirファイルを辿るのを拒否することで実現しました。¹ どちらも新しい防御策を発明するのではなく、不変条件を回復させるパッチなのです。

The Steve Testは次の糸を引っ張ります。Blakeは自分の名前をこれに署名するだろうか？¹³ この6週間におけるClaude Codeに対する答えはノーです。ベンダーがこのクラスのバイパスに2度署名し、出荷し、パッチを当てているからです。それはベンダーが修正すべき水準です。Minimum Worthy Productは、その署名が指す基準です。¹⁴ 最小限とはスコープの制約であり、品質の値引きではありません。最小限の実用可能（minimum viable）な信頼ダイアログとは、安価なケースをブロックするダイアログです。最小限の値する（minimum worthy）信頼ダイアログとは、ユーザーの判断前にリポジトリのバイトを解釈することを拒否するロード順序の最初のステップなのです。出荷する製品とは、許可されるまで解釈することを拒否するバイトのことなのです。

不変条件が要求する3つの修正

ルールは不変条件です。3つのパターンがそこから直接導かれます。

一方向のゲート。 信頼を作るコードが読むのは、パス、ユーザーのクリック、そしてワークスペース外の~/.claude.jsonに永続化された信頼状態のみです。¹⁵ それ以外は何も読みません。ワークスペースファイルが信頼決定に貢献するようなリファクタリングはすべてリグレッションです。

パス解決を介した推移的信頼の禁止。 望ましい不変条件は、ワークツリー、サブモジュール、includeファイル、シンボリックリンクのターゲットがそれぞれ独自のプロンプトを得ることです。一方、Visual Studio CodeのWorkspace Trustでは親フォルダの信頼がサブフォルダにも適用されることを許容しており、その選択が、パス解決が偽装されたときに~/Projectsのような広範な親パスへの信頼を悪用される原因となります。より厳格なルールは数回余分なダイアログを払って、推移的信頼のサーフェス全体を取り除きます。緩いルールは摩擦を低く保ちますが、パス解決のバグが信頼解決のバグになることを受け入れることになります。¹¹

信頼読み込み順序のリグレッションテストにおける敵対的フィクスチャ。 カナリアとなるワークスペースファイルをコミットする、意図的に細工された敵対的リポジトリです。テストは、ダイアログが確認される前にどのコードパスもそれらのカナリアを読まないことをアサートします。ランタイムへの将来の変更が信頼評価中にカナリアファイルを読んでしまった場合、ビルドが失敗します。CWE-501、Trust Boundary Violation（信頼境界違反）は、公開されたアドバイザリですでに使われているより具体的なCWE-807やCWE-20/CWE-77の分類と並んで、テスト分類で追跡する価値のある、より広いファミリーです。¹⁶

3つのいずれもコストが高くありません。1つ目はコードの不在です。2つ目はユーザーから見える摩擦のコストです。3つ目はエンジニアリングの一過、加えてその後の規律です。信頼ブートストラップの侵害は、通常の多層防御の姿勢が当てはまらないカテゴリーです。なぜなら、信頼の下流のすべての層が、ワークスペースが作る手助けをしたばかりの信頼決定に対して動作するからです。信頼の外側での防御は、足場の層では構築不可能です。足場こそが、信頼解決後にワークスペースが読み込めるものそのものだからです。

ベンダーが不変条件を出荷しなければなりません。信頼ダイアログバイパスのCVEは、ベンダーがその水準を満たしているかを観察者が測る方法です。6週間で2件はノイズではありません。これは、不変条件がビルドが強制するアサーションとしてテストスイートにエンコードされていないことを示すシグナルです。エンコードされるまで、このクラスの次のCVEは、10番目の入力を見つけるかどうかの問題なのです。

リポジトリに自身の信頼性を投票させてはなりません。信頼は、評価対象の成果物が手助けしてはならない唯一の決定です。エージェントの防御の他のすべての層（フック、スキル、バリデータ、ディテクタ、ガード）は、その単一の票決の下流に存在しています。票決が不正に操作されているとき、下流の作業は家具にすぎません。キャビネットの表面の仕上げは、裏側を救えません。

FAQ

Claude Codeの信頼ダイアログバイパスとは何ですか？

Claude Codeの信頼ダイアログバイパスとは、ユーザーが明示的に承認する前に、信頼されていないワークスペースが信頼済みとして扱われてしまうことを指します。2026年3月のCVEでは、信頼が評価される前に、リポジトリ管理下の設定が権限モードに影響を与えていました。2026年4月のCVEでは、細工されたgitワークツリー/commondirのレイアウトによって、すでに信頼されているパスを経由して信頼が解決されてしまいました。

~/.claude.json内の信頼済みパスをどう絞り込むべきですか？

~/.claude.jsonを開き、projectsマップを確認してください。hasTrustDialogAcceptedがtrueになっているエントリで、もうアクティブなコードを保持していないディレクトリ、~/Projectsのような広範な親パス、ワークツリー隣接のレイアウトと重なるあらゆるパスを探してください。リポジトリごとの信頼はダイアログを増やしますが、承認された1つの親パスがすべての子を黙ってカバーしてしまうことを防ぎます。

Claude Codeにとって親パスへの信頼がなぜ危険なのですか？

親パスへの信頼が危険なのは、承認された1つのディレクトリが多くの子ワークスペースをカバーし得るからです。パス解決が偽装されたり、悪意のあるワークツリーがその親を指し戻したりすると、子リポジトリは付与されたことのない信頼を継承してしまうことがあります。リポジトリごとの信頼は摩擦を増やしますが、無関係なリポジトリ間での推移的信頼を防ぎます。

信頼ダイアログバイパスを防ぐ不変条件は何ですか？

不変条件はこうです。ユーザーがワークスペースパスを明示的に信頼するまで、ワークスペース内のバイトを一切解釈しないこと。信頼コードが読んでよいのは、パス、ユーザーのクリック、そしてリポジトリ外の永続化された信頼状態のみです。ダイアログの前に.claude/settings.json、CLAUDE.md、.mcp.json、フック、スキル、commondir、その他リポジトリ管理下のファイルを読んではなりません。

References