AIエージェントに外部サイトを閲覧させる機能は、便利さと引き換えに「どのドメインなら安全に見せていいか」という判断を運用側に迫る。Claude CodeのWebFetchツールで見つかったある脆弱性は、この判断を人間ではなくベンダー側の既定設定に委ねた場合に何が起こり得るかを示す事例だった。GitHubの公式セキュリティアドバイザリを直接確認できたので、内容を整理したい。

何が起きていたか

GitHubのセキュリティアドバイザリ（GHSA-fg94-h982-f3mm、CVE-2026-54316）によると、Claude CodeのWebFetchツールはhuggingface.coをパス指定なしの「ベアホスト名」として既定で許可対象に含めていた。これはAIモデルの配布サイトとして日常的にアクセスする正当な理由があるドメインだが、パスを指定しない許可設定だったため、そのドメイン配下のどんなパスへのアクセスも、許可プロンプトを出さずに——つまり--allowedToolsのような制限も効かないまま——通ってしまう状態になっていた。

問題は、Hugging Faceが誰でも自由にリポジトリを公開できるプラットフォームだという点と組み合わさって顕在化する。攻撃者は自分の管理下にあるモデルリポジトリを用意し、何らかの経路でエージェントのコンテキストに「このURL（例：/resolve/main/config.jsonのようなパス）をWebFetchで取得しろ」という指示を紛れ込ませる。Hugging Face側はファイルへのアクセスをダウンロード数としてサーバー側でカウントしている。攻撃者はこのダウンロードカウンターを一種の秘密の通信路（サイドチャネル）として使い、盗み出したいデータ——ファイルの中身・環境変数・コマンドの出力など——を1文字ずつ符号化してエンコードし、外部から見えるダウンロード数の変化として持ち出すことができた。

アドバイザリでは影響範囲を@anthropic-ai/claude-codeのバージョン0.2.54以上2.1.163未満、修正版は2.1.163、深刻度はCVSS v4で6.0（Moderate）、公開日は2026年6月13日、報告者はhackerone.com上のアカウント「novee」（Novee Securityの研究者）と記載されている。通常のアップデートを追随していれば既に修正済みのバージョンを使っているはずだが、バージョンを固定して長期間更新していない環境では影響が残る可能性がある。

なぜ「既定の許可」が危ういのか

Claude Codeの公式ドキュメントを確認すると、WebFetchはドメイン単位で許可ルールを設定する仕組み（WebFetch(domain:host)の形式）を持っている。これ自体は理にかなった設計で、毎回すべてのURLで確認を求められては実用にならない。今回の問題は、この仕組みの使い方——パスを指定しないベアホスト名での許可——が、対象ドメインが「誰でも任意のコンテンツを公開できる場所」だった場合に、ドメイン単位の信頼がそのままそのドメイン上の悪意あるコンテンツへの信頼にすり替わってしまう、という点にある。

さらに厄介なのは、この経路が悪用されていることが被害者側から見えにくいことだ。ダウンロード数の増減という一見無害な現象の裏でデータが漏洩していても、通常のログ監視やネットワーク監視では異常として検知しづらい。

Black Hatで示された、1社に留まらないパターン

海外の複数のセキュリティメディア（The Hacker News、GBHackersなど）の報道によれば、2026年8月のBlack Hat USA 2026で、この脆弱性を報告したのと同じセキュリティ企業Novee Securityが、GitHubのIssueやPRのように外部の第三者が自由に書き込める場所を起点に、Claude Codeに限らずGoogleのGemini CLIやGitHub Copilotのコーディングエージェントも同様の構造で乗っ取り、CI実行環境のシークレット（GitHubトークンやAPIキーなど）に到達できるという趣旨の研究を発表している。個々の脆弱性の技術的な中身はツールごとに異なるが、「外部から書き込める入力が、そのままエージェントのツール実行に届いてしまう」という骨格は共通している。

⚠️ このBlack Hatでの発表内容についてはThe Hacker News・SecurityWeek・Novee Security自身のブログなど一次情報にあたるURLがいずれも今回のセッションのネットワーク制限で直接確認できなかったため、上記は複数の独立した報道が一致する範囲の骨格のみを採用している。Gemini CLI側の個別のCVE番号やCVSSスコア、発表セッションの詳細な名称までは確認が取れておらず、本稿では踏み込んだ記載をしていない。

中小企業が実務で押さえるべき3点

  1. 「既定で許可されている」を「安全」と読み替えない：ベンダーが用意した許可リストは利便性のための設計であって、そこに含まれるドメインの中身まで保証しているわけではない。特に誰でもコンテンツを公開できる共有プラットフォームがベアホスト名で許可されている場合は要注意
  2. バージョンを固定運用しているなら、更新の追随を仕組み化する：修正版がリリースされていても、古いバージョンのまま使い続けていれば意味がない。CI環境やローカル環境のバージョンを定期的に確認する運用を組み込む
  3. 外部から書き込める入力（Issue・PR・Webページの内容など)がエージェントのツール実行に直結する経路がないか棚卸しする：今回の一連の報道が示すように、この構造自体はベンダーを問わず起こり得る。自社のCI/CDやエージェント運用でどこにこの経路があるかを把握しておく

「信頼できるドメイン」の線引きは自社でも持つ

以前取り上げたGitHub Actionsの脆弱性では「外部から届く入力を無条件に信用しない」という教訓を紹介したが、今回の事例はその一段手前——「ベンダーが既定で信頼しているものを、自社もそのまま信頼していいか」という問いを投げかける。ベンダー側の既定設定に頼り切るのではなく、自社の環境で本当に必要な範囲だけを許可する、という発想の切り替えが要る。これもハーネスの考え方——構造で安全を担保する——の一部だ。

自社のAIエージェント運用でツールの権限設計をどう見直せばいいか整理したい場合は、パイロット・構築のフェーズで一緒に詰められる。まずは30分の無料診断から相談してほしい。