powered by TechFeed
表示モード
Deep Dive

ブランチ名のセミコロン1文字でAIエージェントのGitHubトークンが盗まれた — 本当の問題はバグではなく「過剰な権限」だ

10月1日、Canio Campanielloが「A Semicolon in a Branch Name Was All It Took to Steal an AI Agent's GitHub Token」と題した記事を公開した。この記事では、ブランチ名にセミコロンを仕込むだけでOpenAIのCodexエージェントが保持するGitHubトークンを窃取できた脆弱性と、AIエージェントに過剰な権限を与えることの危険性について詳しく紹介されている。

10月1日、Canio Campanielloが「A Semicolon in a Branch Name Was All It Took to Steal an AI Agent's GitHub Token」と題した記事を公開した。この記事では、ブランチ名にセミコロンを仕込むだけでOpenAIのCodexエージェントが保持するGitHubトークンを窃取できた脆弱性と、AIエージェントに過剰な権限を与えることの危険性について詳しく紹介されている。


セミコロン1文字でトークンが盗まれた仕組み

今年3月、セキュリティ企業BeyondTrustのPhantom Labsが、OpenAIのAIコーディングエージェント「Codex」にクリティカルなコマンドインジェクション脆弱性を開示した。

攻撃の手順はシンプルだ。Codexはタスク実行時にコンテナを起動し、指定されたブランチをcloneするが、その際にブランチ名をシェルコマンドへそのまま渡していた。つまり、;・&&・|・$()・バッククォートといったシェルのメタ文字がサニタイズされずBashに渡る。

攻撃の概念実証(PoC)は次の通りだ:

  1. セミコロンを含む悪意あるブランチ名(例:main;malicious-command)を用意し、セミコロンで意図したgitコマンドを終端させる
  2. 続けて git remote get-url origin の出力(URLにGitHub OAuthトークンが平文で含まれる)をファイルに書き出すコマンドを注入する
  3. エージェントへのプロンプトで「そのファイルを読んで」と指示する

Codexは設計通りに動いた。ファイルを読み、内容をタスク出力として返した。盗まれたトークンはエージェント自身の出力の中に現れた。

この脆弱性はCodexが提供するすべての実行面——ChatGPTウェブUI、CLI、SDK、IDE拡張——に影響した。さらに研究者は、リポジトリを共有する複数ユーザーへの攻撃を自動化できることも確認している。OpenAIが修正を完了しクリティカル評価で公開されるまでに、約6週間を要した。


本当の問題はバグではなく「爆発半径」だ

サニタイズのバグはパッチで直る。しかし盗まれた認証情報がどれだけの価値を持つかは、バグとは別の問題だ。

Teleportが2026年に実施した「State of AI in Enterprise Infrastructure Security」レポート(CISOおよびセキュリティアーキテクト205人へのインタビュー)は、その深刻さを数字で示している:

  • AIシステムに過剰な権限を与えている組織は、最小権限を徹底している組織と比べてセキュリティインシデントが4.5倍多い(※元記事では相関として報告されており、因果関係を示すものではない)
  • **70%**の組織が、同じタスクを担当する人間より高いアクセス権をAIエージェントに与えていると認めている
  • **67%**の組織がAIシステムに静的なクレデンシャル(使い回しの固定トークン)を使い続けている

Codexの脆弱性はこの問題を具体化する。盗まれたトークンが1つのブランチにしかアクセスできなければ、被害は軽微だ。しかし組織全体のリポジトリへのアクセス権を持っていれば、コーディングアシスタントを起点とした組織規模のGitHub侵害に発展する。

Graviteeの「2026 State of AI Agent Security」レポートも同様の乖離を示している。エグゼクティブ回答者の**82%がAIエージェントのポリシーで不正アクセスを防止できると回答した一方、実際に監視・保護されているAIエージェントの割合は平均47.1%**にとどまる。この差こそが、誰も気づかないまま本番インシデントに至る隙間だ。


エージェントを本番に出す前に確認すること

記事は具体的なチェック項目を列挙している:

  • クレデンシャルのスコープはタスク単位にとどめる。 エージェントが1リポジトリへのPR作成しか必要としないなら、設定した開発者と同じ権限幅のトークンを持たせる理由はない。
  • エージェントのタスクフローが受け取る自由入力フィールドはすべてシェルへの非信頼入力として扱う。 ブランチ名、ファイルパス、コミットメッセージ、チケットタイトル——どれも今回と同様にサブプロセスへ無害化なしに渡ればコマンドインジェクションになりうる。
  • 静的トークンより短命・使い捨てのクレデンシャルを選ぶ。 タスク単位でスコープを切り、完了後に失効するトークンなら、盗まれてもその1タスク分の被害で済む。
  • 「ポリシー文書があること」ではなく「エージェントの実際のアクセス範囲が答えられること」を求める。 「このエージェントのクレデンシャルは今何にアクセスできるか」をリポジトリとスコープの具体的なリストで即答できないなら、それはポリシーと現実の乖離だ。

まとめ

Codexの脆弱性自体は修正済みだ。しかし今回の一件が示す本質的な教訓は、「サニタイズを怠るな」という技術的な注意喚起にとどまらない。次の脆弱性が来たとき、被害が軽微で済むかどうかは、すでに今の権限設計が決めている。 静的クレデンシャルと過剰なスコープの組み合わせは、あらゆる脆弱性の爆発半径を最大化する。サニタイズバグは見つけやすく、パッチで封じられる。しかし権限スコープの肥大化は静かに積み上がり、次の攻撃者を待ち続ける。AIエージェントを本番環境に展開する組織が今すぐ問うべきは、「バグはないか」ではなく「バグがあったとき何が失われるか」だ。

詳細はA Semicolon in a Branch Name Was All It Took to Steal an AI Agent's GitHub Tokenを参照していただきたい。