セキュリティ

GitHub RCE脆弱性 CVE-2026-3854 — git push一発で全テナント侵害できた仕組み

securitygithubcvesupply-chaindevops

はじめに

2026-04-28、Wiz Researchが公開したGitHubのRCE脆弱性「CVE-2026-3854」の詳細レポートが、Hacker NewsとRedditの双方でトップ常連となっている。CVSSは8.7。認証済みユーザーが標準のgitクライアントからgit pushを一回叩くだけで、GitHubのバックエンドサーバ上で任意コード実行が可能だったという、CI/CDサプライチェーン全体を根本から揺さぶる内容だ。

本記事ではこの脆弱性の技術的な仕組みを噛み砕いた上で、なぜこれがエンジニアにとって他人事ではないのか、そしてGitHub.comユーザー・GHES運用者・GitHub Actions利用者がそれぞれ今どう振る舞うべきかを整理する。

何が起きたのか — タイムラインと影響範囲

Wiz Researchが脆弱性を発見し、GitHubに報告したのが2026-03-04。GitHub.comではわずか6時間で修正がデプロイされ、3月10日にGHES向けパッチがリリース、4月28日に公開ディスクロージャーという流れだ。スピード対応自体は評価できるが、問題はそこではない。

影響の「広さ」と「深さ」が、過去のGitHub関連脆弱性とは桁違いだった。

  • GitHub.comのケース: マルチテナント構成のため、共有ストレージノード上で動く悪意あるコードは、組織やユーザーを横断して数百万のリポジトリを読み取り可能だった。プライベートリポジトリでも例外ではない。
  • GitHub Enterprise Server (GHES) のケース: サーバ全体がフル権限で侵害される。社内のコード資産・シークレット・CIランナーが事実上すべて露出する。
  • 未パッチ実態: Wizが公開時点で計測したところ、GHESインスタンスの88%が未パッチで運用されていた。これは「気付いた時にはもう遅い」可能性が極めて高い数字である。

加えて興味深いのが発見手法だ。Wizは「IDA MCP」を活用したAI支援リバースエンジニアリングでGitHubのコンパイル済みバイナリを解析し、内部プロトコルを再構築したと明言している。AI時代のセキュリティリサーチが、防御側だけでなく攻撃面の発見でも実戦投入されつつあることを示す好例である。

技術詳細：babeldのX-Statヘッダーインジェクション

CVE-2026-3854の本体は、CWE-77（Improper Neutralization of Special Elements、特殊文字の不適切な無害化）に分類されるシンプルなインジェクションだ。シンプルだからこそ、長年見逃されていた。

GitHubは内部でbabeldというgitプロキシを使い、ユーザーからのgit pushを解析して内部マイクロサービスへ転送している。ユーザーはgit push -o key=valueの形式でpush optionsという機能を通じて任意の文字列を送ることができ、babeldはこの値をセミコロン区切りの内部ヘッダーX-Statにそのまま埋め込んでいた。

問題は、セミコロンがX-Statのフィールド区切り文字でありながら、push optionsの値に含まれるセミコロンをサニタイズしていなかった点にある。攻撃者はgit push -o "rails_env=test;custom_hooks_dir=/tmp/evil"のような値を送ることで、内部ヘッダーに新しいフィールドを後付けで注入できた。

悪用は3段階で進む。

  1. rails_envの上書きでサンドボックスをバイパス。 本番環境向けのサンドボックス制約を、非本番値（test等）で無効化する。
  2. custom_hooks_dirで任意のフックディレクトリを指定。 GitHubのgit hookを、攻撃者が制御するディレクトリから読み込ませる。
  3. パストラバーサルで任意バイナリを実行。 既存のバイナリやアップロード済みファイルを指す相対パスを工夫し、バックエンドプロセス権限で実行に持ち込む。

仕組みだけ見ると教科書的な「区切り文字のサニタイズ漏れ」だが、これがマルチテナント基盤の最深部で走っていたのが恐ろしい点だ。1つのgit pushが、共有ストレージ全体への扉を開いていた。

エンジニアへの影響と取るべき対応

「自分はGHES運用していないし、GitHub.comも対応済みだから関係ない」と思った読者は、ぜひもう一度立ち止まってほしい。CVE-2026-3854は単発の事件ではなく、ここ1年のGitHubエコシステムへの一連の攻撃の延長線上にある。

  • 2025年3月: tj-actions/changed-filesの改ざんで2万3千リポジトリのCIシークレットが露出
  • 2026年3月: trivy-action供給チェーン侵害
  • 2026年4月: 本件CVE-2026-3854の公開

つまり攻撃者の主戦場は「アプリケーションのコード」から「CI/CDインフラそのもの」へ完全に移っている。GitHubも2026年セキュリティロードマップで、ワークフローの依存関係をSHAで決定論的にロックするdependencies:セクションや、ルールセットによる集中ポリシー制御、ランナー出力先のegress制御を発表しており、業界全体がこの認識を共有している。

開発者として今すぐ取れる現実的なアクションは以下の通り。

  • GHES運用者: ただちに3.19.3 / 3.18.6 / 3.17.12 / 3.16.15 / 3.15.19 / 3.14.24以上へアップグレード。Wizが脆弱インスタンスを検出するクエリを公開しているので、自社環境のスキャンも併用する。
  • GitHub.comユーザー: 個別対応は不要だが、3月初旬の不審なアクセスログ・トークン使用履歴は念のため確認する価値がある。
  • GitHub Actions利用者全般: Actionの参照をバージョンタグから40文字のコミットSHAへ固定する。pull_request_targetを使って外部PRのコードをチェックアウトしているワークフローは特に高リスクなので、トリガー分離か廃止を検討する。
  • 組織として: 「内部プロトコルだから安全」という前提を捨て、区切り文字ベースのプロトコルにユーザー入力を流す箇所を棚卸しする。babeldのパターンは自社のサービスにも潜んでいる可能性が十分ある。

まとめ

  • CVE-2026-3854は、babeldのX-Statヘッダーへのセミコロンインジェクションで、git push一発からRCEに到達できた重大脆弱性。
  • GitHub.comはマルチテナント構造ゆえに「数百万リポジトリ横断アクセス」が可能、GHESはサーバ全体侵害が成立した。
  • GitHub.comは6時間で修正、GHESパッチも提供済みだが、公開時点で88%が未対応という運用上のギャップが残る。
  • CI/CDインフラ自体への攻撃は2025年から増勢一途で、Actions利用者もSHA固定・pull_request_targetの見直しは即実行すべき。

git pushという最も日常的な操作が攻撃ベクターになりうる時代において、「内部プロトコルなら安全」という思い込みはリスクそのものだ。今回の事件は、CI/CDサプライチェーンを構成するすべての層を疑う訓練の機会として受け止めたい。

ソース

Back to articles