AIコーディングエージェント 脆弱性｜GitHub Issue起点でCI/CDシークレットが漏れる攻撃チェーン

AIコーディングエージェント 脆弱性は、Claude Code・Gemini CLI・OpenAI Codexという主要3社の製品で、独立に、しかし同じ形で見つかった。Black Hat USA 2026で開示された研究によれば、攻撃の起点は「誰でも作成できるGitHub Issue」で、そこからCI/CDワークフローが握るシークレット（APIキーやトークン）へ到達する経路が、3社それぞれのエージェントで成立していたという。単発のCVEではなく、AIエージェントとシステムを仲介する「ハーネス」の設計そのものが攻撃面になっていることを示す事例だ。

エージェント型ツール・サプライチェーン攻撃全般の防御チェックリストは サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

AIコーディングエージェント 脆弱性の正体：GitHub Issueを起点にCI/CDシークレットへ到達する仕組みとタイムライン

3社のAIコーディングエージェントは、いずれもGitHub上のリポジトリと連携し、Issueへのコメントやラベル付けをトリガーにCI/CDワークフロー上でエージェントを起動できる。この設計自体は便利な自動化機能だが、今回報告された攻撃チェーンはその設計の裏側を突く。

流れは次の通りだ。まず攻撃者は、対象リポジトリに誰でも投稿できるGitHub Issueを作成する。リポジトリ側のCI/CDワークフローが on: issues のようなIssue関連のイベントをトリガーにしていると、Issue作成だけでワークフローが起動する。このワークフロー内でAIコーディングエージェントが呼び出され、Issue本文を読み込んで処理する際、エージェントはその本文を「信頼できる指示」として扱ってしまう（プロンプトインジェクション）。ワークフローがCI環境のシークレット（APIキー・デプロイトークン等）にアクセスできる状態であれば、エージェントは細工されたIssue本文の指示に従い、そのシークレットを何らかの通信路経由で外部へ持ち出せてしまう。

タイムラインとして確認できているのは以下の通りだ。

・2026-08-07：The Hacker Newsが、Claude Code・Gemini CLIの脆弱性がGitHub Issueを起点にCI Workflow Secretsへ到達することを報じる
・2026-08-08：Cloud Security Allianceがresearch noteを公開し、3社（OpenAI Codexを含む）の技術詳細・CVE番号・修正版をまとめる
・Black Hat USA 2026：本件を含む攻撃チェーンが統合的に開示される（開示の正確な日付は各社アドバイザリ側では明示されておらず、上記2媒体の報道を通じて確認できる範囲にとどまる）

同種の設計欠陥がプロトコルレベルで報告された例としては、MCP脆弱性！STDIOトランスポートの設計欠陥で20万台のサーバーがRCEの危険に——OX Securityが警告 がある。今回の3社横断の事例は、プロトコルではなく「エージェントが外部入力をどこまで信頼するか」というハーネス側の設計判断が焦点になっている点が異なる。

Claude Code・Gemini CLI・OpenAI Codex：3社のAIコーディングエージェント 脆弱性を比較する

3社の脆弱性は攻撃の起点こそ共通するが、具体的な欠陥の型とベンダーの対応は大きく異なる。

もっとも評価が割れているのがClaude Codeだ。NVDはCVSS v3.1で9.1というCritical寄りのスコアを付けているのに対し、Anthropicは自己申告のCVSS v4で6.0（Moderate）としている。両者の評価がなぜ食い違うのか、その根拠を明示した一次ソースの記述は確認できておらず、攻撃の前提条件（HuggingFaceという事前許可済みドメインが必要になる等）の評価の重み付けが異なる可能性はあるが、断定はできない。この食い違いの理由自体は本記事執筆時点で未確認として扱う。

なお、脆弱性の対象が「Claude Code本体（npmパッケージ @anthropic-ai/claude-code）」なのか「CI連携で使われることが多いGitHub Action版（anthropics/claude-code-action）」なのかは、参照した記事群の間でも表記が揺れている。GitLab Advisory Databaseの記載はnpmパッケージを対象としているが、CI/CDでの実運用ではGitHub Action経由の利用が主流であるため、どちらが一次責任箇所かは公式アドバイザリの原文を個別に確認するのが確実だ。

Gemini CLI側は、CVE-2026-12537という番号とGHSA-wpqr-6v78-jr5gというGitHub Advisory IDの両方が資料上に現れる。GHSA-wpqr-6v78-jr5g自体は2026-04-24公開だが、2026-08のBlack Hat開示に関する報道でCVE-2026-12537という番号も併記されている。この2つが同一脆弱性への後日のCVE採番なのか、別物を指すのかは、本記事の調査範囲では確定できていない。

Gemini CLI固有の技術的な欠陥は2つある。1つはヘッドレスモードでワークスペースを自動的に信頼してしまう挙動、もう1つは --yolo フラグを使った場合にツール実行のallowlist（許可リスト）チェックがバイパスされてしまう挙動だ。Googleはこの2つの設計欠陥を1本のアドバイザリで同時に修正している。

OpenAI Codexは唯一、今回の件をCVEとして採番していない。OpenAIの立場は「マルチパス構成において前段の出力が後段の信頼されたシステムプロンプト文脈として扱われるのは設計上の挙動であり、脆弱性ではない」というものだ。対応としてはパッチではなく、ジョブの分離とread-onlyサンドボックスの徹底、そして公式ドキュメントへの「instruction files（Issue本文のような外部入力ファイル）は信頼できない入力として扱う」という明記に留めている。脆弱性認定の基準がベンダーごとに異なることを、この3社の対応差が端的に示している。

Claude Code単体の脆弱性を広く一覧したい場合は、Claude Code セキュリティ｜サンドボックスの守備範囲と公開アドバイザリで見る攻撃面・確認コマンド も参照してほしい。本記事はそのうちCVE-2026-54316の1件を、Gemini CLI・OpenAI Codexとの横断比較という切り口で深掘りする専用記事という位置づけだ。

自律型ペネトレーションテストの標準化という別角度からAIエージェントのセキュリティを見るなら、OWASP APTS｜AIエージェント時代の自律型ペネトレーションテスト基準を読む も関連する。

自分の環境が影響を受けるか確認する方法

実際に確認すべきポイントは、①各エージェントのバージョンが修正版以降か、②CI/CDワークフローに「Issueトリガー」と「シークレット参照」が同居していないか、③（Claude Codeの場合）WebFetchの許可リストにパス制限のないベアホスト名が残っていないか、の3点になる。

# インストール済みバージョンの確認（各社の修正版と比較する）
npm ls -g @anthropic-ai/claude-code 2>/dev/null || claude --version
npm ls -g @google/gemini-cli 2>/dev/null || gemini --version

本記事の検証環境で実際に上記コマンドを実行したところ、claude --version は 2.1.234 (Claude Code) を返した。これはClaude Codeの修正版である2.1.163より新しく、この環境のClaude Codeは修正済みバージョンだと確認できる。一方でGemini CLIはこの検証環境に導入されておらず、npm ls -g @google/gemini-cli は空、gemini --version は「コマンドが見つからない」というエラーになった。両方のコマンドを併記しているのは、npm経由の導入かバイナリ配布かで確認方法が変わりうるためだ。

# CIワークフローで、Issueトリガーとシークレット利用が同居していないか確認
grep -rln "on:" .github/workflows/*.yml 2>/dev/null | xargs grep -l "issues:" 2>/dev/null
grep -rn "run-gemini-cli@" .github/workflows/*.yml 2>/dev/null

このコマンドを当サイト自身のリポジトリで実際に実行したところ、dreaming.yml が1件ヒットした。ただし中身を確認すると、これは on: issues というIssueトリガーではなく、permissions: issues: read（closed issueの収集に使う読み取り権限）が偶然 issues: という文字列にマッチしていた誤検出だった。実際のトリガーは schedule と workflow_dispatch のみで、Issue作成では起動しない。このコマンドは足がかりの一覧を出すだけで、ヒットしたファイルは必ず on: ブロックの中身を目視確認する必要がある——これは実際にコマンドを動かして初めて分かった注意点だ。

# Claude CodeのWebFetch許可リストにベアホスト名（パス制限なし）が残っていないか確認
grep -n "huggingface.co" .claude/settings.json 2>/dev/null

こちらも当リポジトリで実行したが該当行は無かった（本サイトはClaude CodeのWebFetch許可リストにHuggingFaceドメインを登録していないため）。読者は自分のプロジェクトの .claude/settings.json や、CI上のワークフロー定義ファイルに対して同じコマンドを実行し、Issueトリガーとシークレットの同居、パス制限のないベアホスト名の許可が無いかを確認してほしい。

なぜハーネスが脆弱性の主戦場になるのか

3社の脆弱性を並べると、共通する構造が見えてくる。AIコーディングエージェント本体（LLM）が持つ「指示に従う」という性質自体は変えられない。だとすれば、エージェントとシステムを仲介する「ハーネス」——どの入力を信頼するか、どのツール呼び出しをどこまで許可するか、シークレットへのアクセス範囲をどう限定するか——の設計が、事実上の防御境界になる。

Claude Codeの事例は、WebFetchの許可リストが「ドメイン単位」で緩く設定されていたことが起点だった。事前に許可されたHuggingFaceドメインへの通信自体は正当な機能だが、パスやリクエストの内容までは検証されておらず、その正当な通信路がAPIキーを1文字ずつ持ち出す帯域外チャネルに転用された。Gemini CLIの事例は、ヘッドレスモード（人間の確認を挟まない自動実行モード）でワークスペースを自動信頼する設計と、--yolo フラグによる許可リストバイパスという、どちらも「利便性のために追加された緩和機構」が攻撃面になっていた。OpenAI Codexは、マルチパス構成において前段の処理結果が後段では「信頼されたシステムプロンプト文脈」に昇格してしまう設計自体をOpenAIが仕様と認めており、これも広義には同じ構造の問題だ。

言い換えると、今回の一連の脆弱性は個別のバグというより、「AIエージェントに何をどこまで自動で信頼させるか」というハーネス設計の根本的な難しさを、3社が独立に踏み抜いた結果と見ることができる。CI/CD環境はシークレットへのアクセスとエージェントの自動実行が両立する場所であるため、この種の設計判断が特に高い代償を伴う。

対策とアップデートの進め方

対応は各社の修正版へのアップデートが前提になるが、それだけでは今回の構造的な問題を完全には解消しない。

・バージョンアップデート：Claude Codeは2.1.163以上、Gemini CLIは0.39.1／0.40.0-preview.3以上（run-gemini-cliは0.1.22以上）へ更新する。OpenAI Codexは対応するパッチが無いため、後述のワークフロー変更を自分の運用に反映する
・CIワークフローの点検：on: issues のようなIssueトリガーと、シークレットへのアクセスが同一ジョブ内に同居していないかを確認する。同居している場合は、Issue本文を処理するジョブとシークレットを使うジョブを分離し、前者の出力を後者が無条件に信頼しないようにする
・許可リストの粒度を見直す：WebFetch等の許可リストを「ドメイン単位」ではなく、必要なパス・リクエスト形式まで絞り込めないか確認する。ドメインが正当でも、パス制限が無ければ帯域外持ち出しの通信路になりうる
・ヘッドレスモード・自動実行フラグの扱いを見直す：Gemini CLIの --yolo のような、確認を省略するフラグをCI環境で常用していないか確認する
・「instruction filesは信頼できない入力」という前提を運用に反映する：OpenAIが採用したこの原則は、他社のエージェントを使う場合にも応用できる。Issue本文・PRコメント等、外部から書き込まれるテキストをエージェントに読ませる箇所では、そのテキストを実行可能な指示として扱わない設計・レビュー運用を検討する

これらのワークアラウンドは、パッチ適用と違って自分のCI設定側の変更が必要になる。特にIssueトリガーからAIエージェントを起動する自動化を既に組んでいるプロジェクトは、ジョブ分離の見直しを優先度高く扱う価値がある。

まとめ：AIコーディングエージェント 脆弱性から読み取れること

GitHub Issueという「誰でも作れる入力」から、CI/CDが持つシークレットへ到達する攻撃チェーンが、Claude Code・Gemini CLI・OpenAI Codexという3社のAIコーディングエージェントで独立に成立していた。ベンダーの対応はAnthropicが自己申告でModerate評価、GoogleがCriticalとして即修正、OpenAIが脆弱性非認定という三者三様で、脆弱性認定の基準そのものがベンダーごとに異なることが分かる事例でもある。

読者自身のプロジェクトでAIコーディングエージェントをCI/CDに組み込んでいる場合は、まずバージョンを確認し、次に本記事のコマンドでIssueトリガーとシークレットの同居を点検してほしい。

参照ソース

・Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets（The Hacker News, 2026-08-07） — 3社横断の攻撃チェーンの概要・タイムライン
・Three AI Coding Agents, One GitHub Issue: CI/CD Secrets Exposed（Cloud Security Alliance, 2026-08-08） — 技術詳細・CVE番号・修正版の一次情報
・Gemini CLI: Remote Code Execution via workspace trust and tool allowlisting bypasses（GHSA-wpqr-6v78-jr5g, GitHub Advisory Database） — Gemini CLI側の公式アドバイザリ
・CVE-2026-54316: Claude Code Out-of-Band Data Exfiltration via Pre-Approved HuggingFace Domain in WebFetch（GitLab Advisory Database） — Claude Code側の公式アドバイザリ