git pushコマンド1つで、GitHubのバックエンドサーバー上で任意のコードを実行できる。そんな深刻な脆弱性が、AIを使ったリバースエンジニアリングによって発見されました。

この記事でわかること：

  • CVE-2026-3854の仕組みと影響範囲
  • WizがAIツール「IDA MCP」で発見に至った経緯
  • GitHub Enterprise Serverユーザーが今すぐ取るべき対策

CVE-2026-3854とは何か

Securing the git push pipeline: Responding to a critical remote code execution vulnerability
How we validated, fixed, and investigated a critical vulnerability in under two hours, and confirmed no exploitation.
The GitHub Blog

2026年4月28日、GitHubはCVE-2026-3854を公開しました。CVSSスコアは8.7（High）で、リモートコード実行（RCE）を許す脆弱性です。影響範囲はGitHub.com、GitHub Enterprise Server、GitHub Enterprise Cloudなど、GitHubのほぼすべてのプラットフォームに及びます。

発見したのはクラウドセキュリティ企業のWizです。2026年3月4日にGitHubのバグバウンティプログラムを通じて報告し、GitHubは2時間以内にGitHub.com上で修正を完了しました。調査の結果、実際の悪用は確認されていません。

脆弱性の仕組み

GitHub RCE Vulnerability: CVE-2026-3854 Breakdown | Wiz Blog
A CVSS 8.7 vulnerability in GitHub Enterprise Server allows remote code execution. Read the threat brief and find vulner…
wiz.io

GitHubの内部では、ユーザーがgit pushを実行すると複数のサービスを経由してコードが処理されます。認証を担う「gitauth」、リクエストを中継する「babeld」、内部RPCサーバーの「gitrpcd」、セキュリティポリシーを強制する「pre-receiveフック」です。

これらのサービス間でメタデータを受け渡す内部プロトコルに「X-Stat」ヘッダーがあります。セミコロン区切りのキー=バリュー形式で、セキュリティ上重要な設定値を含んでいます。問題は、ユーザーが指定するgit pushオプションの値がサニタイズされずにこのヘッダーへ埋め込まれていた点です。

pushオプションにセミコロンを含む値を渡すと、X-Statヘッダーのフィールド区切りとして解釈され、攻撃者が任意のフィールドを注入できます。X-Statヘッダーは「後勝ち」の仕様なので、正規の設定値を上書きできてしまいます。

git push 1回でサーバーを乗っ取る

Wizは3つのフィールド注入を連鎖させて、RCEへ到達しました。

まず「rails_env」フィールドを注入して、フックの実行パスを本番用のサンドボックスから非サンドボックスのパスへ切り替えます。次に「custom_hooks_dir」を注入して、フックスクリプトの検索ディレクトリを攻撃者が制御する場所へ変更します。最後に「repo_pre_receive_hooks」にパストラバーサルを含むフック定義を注入し、サーバー上の任意のバイナリを実行させます。

この3ステップはすべてgit pushのオプションとして渡せるため、標準のgitクライアントだけで攻撃が成立します。特別なツールは不要です。

GitHub Enterprise Serverでは、この攻撃でサーバー全体の制御を奪取できます。GitHub.comでは共有ストレージノード上でコードが実行され、同じノードに格納された数百万件のリポジトリにアクセス可能な状態でした。Wizは自社のテストアカウントのみで影響を検証しており、他のユーザーのリポジトリ内容には実際にはアクセスしていません。

AIがリバースエンジニアリングを変えた

この発見で注目すべきは、AIツール「IDA MCP」が決定的な役割を果たした点です。IDA MCPは、リバースエンジニアリングツール「IDA Pro」とLLM（大規模言語モデル）をModel Context Protocol（MCP）で接続するオープンソースツールです。自然言語で指示を出しながらバイナリ解析を進められます。

WizのセキュリティリサーチャーSagi Tzadik氏は、GitHubのインフラを2024年9月から調査対象にしていたと述べています。しかし、クローズドソースのバイナリを手作業で解析するにはコストが見合わず、着手できていませんでした。従来の手法なら数週間から数カ月かかる作業が、AIツールの活用によって48時間未満でアイデアから動作するエクスプロイトまで到達しています。

Wizはこの脆弱性を「AIを使ってクローズドソースバイナリから発見された最初の重大な脆弱性のひとつ」と位置づけています。コンパイル済みバイナリの解析、内部プロトコルの再構築、ユーザー入力がサーバー動作に影響する箇所の特定といった作業を、AIが高速に処理した結果です。

対策と現状

GitHub.comおよびGitHub Enterprise Cloudはすでに修正済みで、ユーザー側の対応は不要です。

GitHub Enterprise Serverのユーザーは、以下のいずれかのバージョンへアップグレードする必要があります。

  • 3.14.24
  • 3.15.19
  • 3.16.15
  • 3.17.12
  • 3.18.6
  • 3.19.3

Wizの調査によると、公開時点でEnterprise Serverインスタンスの88%がまだ脆弱なバージョンのままでした。プッシュ権限を持つ認証済みユーザーであれば攻撃可能なため、早急な対応が求められます。

セキュリティリサーチの転換点

この事例は、セキュリティリサーチの手法が変わりつつあることを示しています。クローズドソースのソフトウェアは、ソースコードが公開されていないぶん脆弱性の発見が難しく、長期間にわたって重大な欠陥が潜伏しやすい領域でした。AIによるリバースエンジニアリングがそのコストを大幅に下げたことで、これまで調査が及ばなかった領域にもセキュリティリサーチが届くようになります。

一方で、同じ手法は攻撃者も使えます。防御側がAIで脆弱性を見つけるスピードと、攻撃側がAIで攻撃手法を開発するスピードの競争が、今後さらに加速していくことになります。