「セキュリティ優先」を掲げるAnthropicの核心開発ツールClaude Codeのネットワークサンドボックスは、過去5か月間、一度も真に安全ではなかった。
独立セキュリティ研究者である関傲男（Aonan Guan）は5月20日、最新の研究を発表し、Claude Codeのネットワークサンドボックスに2つ目の完全バイパス脆弱性、すなわちSOCKS5プロトコルにおけるヌルバイトインジェクション攻撃を明らかにしました。この攻撃により、サンドボックス内プロセスがユーザーのポリシーで明示的に禁止された任意のホストにアクセス可能になります。これは、2025年10月にサンドボックス機能がリリースされて以来、約5.5ヶ月間で公開された130のバージョンすべてに、完全にバイパス可能なセキュリティ欠陥が存在していたことを意味します。これは、同じ研究者が同じ防衛ラインに対して2回目の完全な突破となります。
Anthropicからの対応は沈黙だった：セキュリティアラートもCVE番号もユーザー通知もなかった。この脆弱性は4月1日のバージョンで静かに修正され、更新ログにはセキュリティ関連の記載は一切なかった。つまり、古いバージョンをそのまま使用し続けているユーザーは、自分の設定したサンドボックスが最初から無効であることに気づく術がなかった。
同じドアの二つの鍵
Claude CodeはAnthropicが2025年初頭にリリースしたAIプログラミングアシスタントで、「ターミナルに常駐するAIエンジニア」として位置づけられています。従来のチャット型コード補完とは異なり、Claude Codeはユーザーのコードベースに対する読み書き権限とコマンド実行能力を備えており、コードのナビゲーション、ファイルの編集、テストの実行などの一連の操作を自律的に実行できます。このような深層的な関与は、極めて高いセキュリティリスクを伴います。モデルがプロンプトインジェクション攻撃によって乗っ取られた場合、攻撃者はユーザーのターミナルと同等の権限を獲得し、ローカル環境変数の読み取り、任意のシステムコマンドの実行、内部ネットワークリソースへのアクセスなどが可能になります。
セキュリティと効率のバランスを取るため、Anthropicは2025年10月にネットワークサンドボックス機能（v2.0.24）を導入し、ユーザーがプロファイルを通じてドメインホワイトリストを設定することで、AIの実行環境の外部ネットワークアクセスを制限できるようにしました。たとえば、allowedDomains: [“*.google.com”] を設定すると、Claude CodeはGoogleおよびそのサブドメインみならず、その他のすべてのトラフィックをブロックします。公式ドキュメントでは明確に「空の配列はすべてのネットワークアクセスを禁止することを意味します」と約束されています。
このメカニズムはSOCKS5プロキシによって実現されています：底层のサンドボックスランタイム（@anthropic-ai/sandbox-runtime）がプロキシサーバーを起動し、サンドボックス内のプロセスは直接ネットワーク接続を開始せず、代わりにプロキシを介して転送されます。プロキシは、settings.jsonでユーザーが設定したホワイトリストに基づいてドメインフィルタリングを実行します。OSレベルのサンドボックスメカニズム——macOSのsandbox-exec、Linuxのbubblewrap——はAgentをローカルループバックアドレスに制限し、外出先の決定はこのSOCKS5プロキシに完全に委ねられます。
Anthropic公式ブログに掲載されたClaude Codeサンドボックスアーキテクチャ図——ユーザーのコマンドはSOCKS/HTTPプロキシを経てサンドボックスに到達し、サンドボックス内のファイル操作およびネットワークアクセスは厳格な権限管理下に置かれる
問題はこのプロキシーの実装にあります。二つの独立したセキュリティ調査が、それが完全に回避可能であることを証明しました。
タイムラインはより深い問題を露呈した：2025年11月26日にリリースされたv2.0.55は最初のバイパスを修正したが、2番目のバイパスはサンドボックスのリリース当日から存在しており、このバージョンにも依然として含まれていた。両方の脆弱性はタイムライン上で重複しており、サンドボックス機能のリリース日から最後の脆弱性が修正されるまで、安全なバージョンは一つも存在しなかった。Anthropicは公式ブログでサンドボックスが「プロンプトインジェクションが発生した場合でも影響を完全に隔離する」と主張したが、この2つのバイパスの存在はその約束を直接覆したものである。
「一回の外部報告は運です。二回は実装の品質問題です。」——関傲男の研究報告より。
完全なバイトゼロのバイパス
二次回避の技術的原理は複雑ではないが、攻撃チェーンの完全性に注目すべきである。
ユーザーがネットワークホワイトリストを設定し、*.google.com へのアクセスのみを許可している。Claude CodeのSOCKS5プロキシは、接続リクエストを受け取った際、JavaScriptのendsWith()メソッドを使用してホスト名のサフィックス照合を行う。攻撃者はホスト名に空バイトを挿入するだけで、attacker-host.com\x00.google.com という文字列を構成できる。JavaScriptは空バイトを通常のUTF-16文字として扱い、endsWith(“.google.com”)はtrueを返すため、プロキシは許可する。しかし、同じ文字列がDNS解決のために下層のC言語関数getaddrinfo()に渡されると、空バイトは文字列の終端として扱われ、実際にはattacker-host.comが解決される。同じバイト列に対して、2つの層のコードが異なる解釈を示す。フィルターはユーザーがGoogleにアクセスしていると判断し、DNS解析器は攻撃者のサーバーに接続していることを認識する。
これは古典的な「パーサー差異」攻撃であり、2005年に発見されたHTTPリクエストサムギングと同一の技術カテゴリ（CWE-158 / CWE-436）に属します。本質的には、同じデータが異なる意味解釈ルールを持つ2つのコンポーネントを通過する際に、攻撃者がこの差異を悪用し、一方の層で「安全」と判断させながら、他方の層で「危険」な操作を実行させるものです。このような脆弱性はネットワークセキュリティ分野で繰り返し発生しており、重要な教訓は常に同じです：信頼境界を越えて渡されるすべての文字列は、上位層が既にチェック済みであるという信頼ではなく、厳格な正規化と検証を経る必要があります。
関傲男は、二つの最小化されたNode.jsスクリプトを使用して脆弱性を再現しました。制御スクリプトは通常のホスト名を使ってSOCKS5接続を開始し、BLOCKEDと返します。攻撃スクリプトはホスト名にヌルバイトを注入し、BYPASSED rep=0x00と返します——これはプロキシが正常に接続を確立し、アウトバウンドチャネルが開かれたことを意味します。Claude Code自体がこの結果を確認しました。
Claude Code v2.1.86における4つの赤色で強調されたステップの完全な脆弱性再現——戦略確認、通常のブロック、ヌルバイト回避、Claude自身による確認
このサンドボックス回避と、関傲男が4月に公開した「コメントと制御」提示詞インジェクション攻撃を組み合わせることで、完全な攻撃チェーンが構築される（参照：三層の防御でも不十分、PRタイトル1本でAPIキーが盗まれる：AI Agentのセキュリティの隙間が再び露呈）。「コメントと制御」研究では、3つのAIプログラミングツールすべてに提示詞インジェクションの攻撃面が存在することが確認されているが、攻撃エントリーポイントはそれぞれ異なる：Claude CodeはPRタイトルのみ、Gemini CLIはIssueのコメントまたは本文を通じて、Copilot AgentはHTMLコメントを利用して隠蔽されたインジェクションを実現する。Claude Codeの例では、PRタイトルが提示詞テンプレートに直接連結され、フィルタリングやエスケープが行われないため、モデルは人間の意図と悪意あるインジェクションを区別できない。
両者を組み合わせる——隠された命令によりAgentがサンドボックス内で攻撃コードを実行し、空バイトインジェクションでネットワークの制限を突破する——環境変数内のAPIキー、AWS資格情報、GitHubトークン、内部APIエンドポイントデータなどが、インターネット上の任意のサーバーに外部に送信可能となる。データはSOCKS5プロキシ自体を通じて流出し、攻撃全体に外部サーバーの中継は不要であり、このプロキシこそがユーザーが安全な境界と信頼するコンポーネントである。攻撃者はリポジトリへの書き込み権限すら必要とせず、公開されたIssueを提出するだけでよい。人間のレビュー担当者はGitHubのレンダリングビューで通常の協力リクエストしか見ず、AI Agentは完全な悪意のあるソースコードを解析する。
Claudeでさえ認める：脆弱性は実在する
この公開内容における重要な詳細の一つは、Claude Code自体から得られたものです。関傲男は、脆弱性の再現コードを直接Claude Codeに渡し、技術的判断を求めました。Claude Codeは、制御テスト（通常のホスト名がブロックされる）と攻撃テスト（ヌルバイトのホスト名でブロックを回避する）を実行した後、明確な結論を導き出しました：
これはネットワークサンドボックスフィルターの本物の回避であり、テストの人工物ではありません。この問題をhttps://github.com/anthropics/claude-code/issuesでAnthropicに報告してください。
テスト対象の製品自体が脆弱性の真実性と深刻性を確認し、自ら報告パスを提示した。この詳細は関傲男によって研究レポートに完全に記録され、The Registerの報道タイトルの源となった——「Even Claude agrees hole in its sandbox was real and dangerous」（Claudeでさえ、そのサンドボックス内の脆弱性は真実で危険であると認めた）。
関傲男の研究カバー——Claude Codeは、自身の脆弱性を提示された後、「これはネットワークサンドボックスフィルターの実際のバイパスである」と認めた。赤い枠で重要な確認文を強調。
Anthropicの返答と5か月の沈黙
脆弱性自体は懸念されるが、Anthropicの対応方法は業界が注目すべきである。
関傲男は2026年4月初旬、HackerOne脆弱性報奨金プログラム（報告番号#3646509）を通じてAnthropicにサンドボックス回避の詳細な報告を提出しました。Anthropicの初期の対応は：
ご報告ありがとうございます。この提出内容を確認したところ、既に追跡中の既存の内部報告と重複していることが判明しました。
報告は直ちに閉鎖されました。関傲男がCVE番号の計画について追及したところ、Anthropicは4月7日に返信しました：
この問題に対してCVEを公開するかどうかはまだ決定しておらず、その決定に関するタイムラインを提供することはできません。
この脆弱性はv2.1.90バージョンで静かに修正されました。セキュリティアラートも、CVE番号も、Claude Codeのセキュリティ推奨ページにも記載がなく、更新ログにはセキュリティ関連の記述は一切ありませんでした。サンドボックスの開始日から存在し、5.5か月間継続し、約130のバージョンにわたる完全な回避手法は、ユーザーにとってはまるで存在しなかったかのようでした。
この処理パターンは初めてではない。最初の回避（CVE-2025-66479）の対応方法はほぼ同じだった：Anthropicは、ユーザー向け製品であるClaude Codeではなく、下位ライブラリである@anthropic-ai/sandbox-runtimeにのみCVEを割り当て（CVSSスコアはわずか1.8、「Low」）、更新ログには「プロキシDNS解決を修正」と記載され、セキュリティ脆弱性には一切言及しなかった。関傲男は研究レポートで次のように記している。「React Server Componentsに深刻な脆弱性が発生した際、ReactとNext.jsはそれぞれ独立したCVEを取得し、MetaとVercelは両方ともセキュリティアラートを発表し、両コミュニティは十分に通知された。しかしAnthropicは異なる対応を選んだ。」現在まで、「Claude Code Sandbox CVE」と検索しても、公式のセキュリティアラートは一切見つからない。
Anthropicは、クレデンシャルの盗難対策としてpsコマンドをブロックしましたが、ブラックリスト方式には根本的な欠陥があります——あるコマンドをブロックしても、攻撃者は無数の代替手段を持っています。正しいアプローチは、Agentがどのツールのみを必要とするかを明確に定義することです。また、「コメントと制御」に関する研究では、Anthropicは脆弱性をCVSS 9.4（Criticalレベル）に格上げし、プライベートバグバウンティプログラムに移行しましたが、広報担当者は「このツールは設計上、プロンプトインジェクションに対して強化されていない」と述べています。ベンダーは自社のモデルのセキュリティ能力を前提としていますが、システムアーキテクチャには深層防御が欠けています。脆弱性がこの欠如を露呈した際、「設計上の制限」という分類が都合よく使われます。これは問題を認める一方で、セキュリティアラートを発表する義務を某种程度免れるための方便です。
より広範な業界の状況では、同様の問題はAnthropicだけにとどまらない。4月に公開された「コメントと制御」に関する研究では、GoogleのGemini CLIとMicrosoft GitHubのCopilot Agentも同様の攻撃面を有することが確認され、3社とも問題を認定・修正したが、いずれもセキュリティアドバイザリーやCVE番号を発行していない。Anthropicは100ドルのバグバウンティを支払い、Googleは1337ドルを支払った。GitHubは当初「既知の問題で再現できない」として報告を閉じたが、逆エンジニアリングの証拠を提示された後、「情報性」としてラベルを付け、500ドルを支払った。合計で1937ドル——この3製品はフォーチュン100企業のほとんどをカバーしている。
偽の安全感は、安全対策が全くないよりもはるかに危険である。サンドボックスがないユーザーは、自分に境界がないことを知っているが、壊れたサンドボックスを持つユーザーは、自分に境界があると信じている。Claude Codeを実行し、ドメインホワイトリストを設定したチームは、5.5ヶ月間リスクに気づかず、アップグレード後に更新ログを見ても、「サンドボックスは常に正常に機能していた」と結論づけるだけである。さらに、脆弱性が公表された際、セキュリティアラートが発出されなければ、ユーザーは自分が影響を受けたかどうかを判断できず、遡及監査の根拠も失われる。
この現状を受けて、セキュリティコミュニティは、信頼をベンダーのサンドボックス実装に単点で集中させることはできないという共通認識を形成し始めています。Claude CodeのSOCKS5プロキシは、GitHubで10個のスターしか持たず、最終更新が2024年6月に止まっているサードパーティのnpmパッケージに基づいて構築されており、JavaScriptとCという2つのランタイム間にセキュリティ境界を設けていますが、信頼の境界部分で最も基本的な規範的処理が欠けています。修正パッチで追加されたisValidHost()関数——空バイト、パーセントエンコード、CRLFなどの不正文字を拒否する役割を担う——は、サンドボックスがリリースされた当日から存在すべきでした。関傲男は、AI Agentを最小権限の原則に従うスーパーエンプロイーと見なす実用的な防御フレームワークを提案しました。その核心は、複数層の防御にあります：
安全な評判は、ブランドの物語ではなく、すべての開示とパッチの透明性によって築かれる。ユーザーが信頼に基づいて資格情報をAgentに委ねるとき、ベンダーには防衛ラインが有効であることを保証する義務があり、それが失敗した場合には即座に通知する義務がある。この両方の点で、AnthropicはClaude Codeサンドボックスで失敗した。
「サンドボックスの最悪の結果は、何らかのものを阻止することではなく、人々に偽の安全意識を与えることです。脆弱性のあるサンドボックスをリリースすることは、サンドボックスをリリースしないよりも悪いことです。」——関傲男
（本記事は钛媒体APPで初公開、著者 | サンフランシスコTech_news、編集 | 焦燕）
参考資料：
1. oddguan.com — 二度目の同じサンドボックス：別のAnthropic Claude Code Networkサンドボックス回避によりデータの不正抽出が可能に（Aonan Guan、2026.05.20）
2. The Register — Claudeでさえ、そのサンドボックス内の穴は実在し、危険だったと認める（2026.05.20）