GitHub の遠隔コード実行（RCE）脆弱性：CVE-2026-3854 の概要

Wiz Research が調査したところ、GitHub の内部 git インフラ構造に重大な脆弱性（CVE-2026-3854）が存在することが判明しました。この脆弱性は GitHub.com および GitHub Enterprise Server の両方に影響を及ぼす可能性がありました。GitHub の内部プロトコルにおける注入 flaw を悪用することで、認証済みのユーザーは標準的な git クライアントだけで 1 つの

git push

コマンドを用い、GitHub のバックエンドサーバー上で任意のコマンドを実行することができました。特に注目すべきは、この脆弱性が AI を用いて閉鎖ソース的二進ファイル内で発見された事例の一つであり、これら flaw の発見方法において大きな転換点を示している点です。システムの複雑さを踏まえても、この脆弱性は悪用しやすすぎることが驚くべき事実です。

GitHub.com におけるこの脆弱性は、共有ストレージノード上での遠隔コード実行 (RCE) を可能にしました。私どもが確認したところ、影響を受けたノードでは他のユーザーおよび組織に所属する数百万個の公開リポジトリとプライベートリポジトリへのアクセスが可能でした。一方、GitHub Enterprise Server (GHES) においては、同様の脆弱性が全サーバーの乗っ取り—including ホストされているすべてのリポジトリや内部シークレットへのアクセス—をもたらしました。

GitHub は我々の報告からわずか 6 時間以内に GitHub.com でこの問題を軽減し、全ての対応可能な GHES バージョンに対するパッチをリリースするとともに、リリース時に CVE を公開しました。GHES のお客様はすぐにアップグレードを行うべきです。現在（執筆時点）のデータによれば、依然として脆弱なインスタンスが全体の 88% に及ぶことが示唆されています。詳細な是正ステップおよび追加的な技術的詳細については、GitHub のセキュリティブログ投稿にて入手可能です。

GitHub は、本プロセスを通じて Wiz が示してきた協働精神、職業性、そしてパートナーシップに大変感謝しています。この規模と深刻さを見いだした事例は稀であり、我々のバグボounty プログラムで最も高い報酬の一つが適用されるべきものでした。また、これは「最も影響力のあるセキュリティ研究は、適切な質問ができる熟練した研究者から生まれる」ということを示す戒めとなります。 landscape が進化する中で、有能なハンターや研究者とのような密接なパートナーシップはかつてなく重要になっています。

Alexis Wales, GitHub CISO

本投稿では、当該脆弱性を分解し、悪用連鎖を解説するとともに、GHES 管理者様が環境を保護するための推奨事項を提供します。

図：脆弱性概要 – 1 つの

git push

が GitHub の内部インフラストラクチャ全体を乗っ取る

必要な対応と軽減措置

GitHub.com: GitHub はすでにこの問題を軽減済みです。GitHub.com のユーザー様は追加の行動を取る必要はありません。
GitHub Enterprise Server (GHES): 即座に対応が必要です。
- GHES バージョン 3.19.3 以降へアップグレードしてください——本リリースでは CVE-2026-3854 を修正しています。

コンポーネント	脆弱なバージョン	修正されたバージョン
GitHub Enterprise Server	<= 3.19.1, 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 および 3.19.3	3.19.3

Wiz を用いて脆弱な GHES インスタンスを検出する

Wiz のお客様は、環境内の脆弱な GitHub Enterprise Server インスタンスを特定するために、Wiz Threat Center で用意された事前構築クエリを使用できます。このクエリにより、当該問題に起因して脆弱なバージョンを実行している全ての GHES インスタンスが特定されます。

図：脆弱な GHES インスタンスを検出するための Wiz Threat Center クエリ

なぜ我々は GitHub の Git インフラストラクチャを調査したか

GitHub は世界中で最大のコードホスティングプラットフォームであり、オープンソースプロジェクトからエンタープライズコードベース、そしてクリティカルインフラに至るまで、数億ものリポジトリが存在する家となっています。その内部 git インフラ——つまりすべての

git push

を処理するパイプライン——はインターネット上の最もセキュリティ حساسة なシステムの一つです。ユーザーがコードをプッシュすると、それは複数の内部サービスを経由しますが、各サービスは異なるプログラミング言語で書かれています。この多サービスアーキテクチャは、各コンポーネントが共有データをどのように解析し、信頼するかという点において不一致が生じる機会を生み出します。

過去にも、GitHub Enterprise Server (GHES) を対象に、まさにこうした種類の脆弱性を Hunting するために調査を行いました。しかし、過去にはこのパイプラインを実行する大量のコンパイルされたブラックボックス二進ファイルを取り出して監査することは、実用的な時間と人的労力を要する非現実的なタスクでした。しかしこれは第 2 の戦いであり、 landscape は変化しました。AI 増強ツールの活用——特に IDA MCP を用いた自動逆符号解析——をすることで、以前はコストが高すぎた作業を行うことができました。AI を活用し、我々は GitHub のコンパイルされた二進ファイルを迅速に分析し、内部プロトコルを再構築するとともに、ユーザー入力がパイプライン全体を通じてサーバーの振る舞いに影響を与えうる箇所を体系的に見出しました。この新しい能力のお陰で、我々は GitHub の多サービスアーキテクチャにおいて入力データが流れ込む方法における根本的な flaw を発見できました。

テクニカルディープダブ

アーキテクチャを理解する

ユーザーが SSH を介して GitHub に対して

git push

を実行すると、リクエストは以下の主要コンポーネントを経由します：

babeld: git プロキシであり、すべての git 操作のエントリポイントです。ユーザーの SSH 接続を受け取り、認証を
```
gitauth
```
に転送します。
gitauth: 内部認証サービスです。ユーザーのクレデンシャルを検証し、ターゲットリポジトリへのプッシュアクセス権があるかを確認するとともに、セッションに適用されるセキュリティポリシー（ファイルサイズ制限、ブランチ命名規則など）を返します。babeld
はこのレスポンスを受け取り、すべてのセキュリティメタデータを含む内部ヘッダーを構築します。
gitrpcd: 内部 RPC サーバーです。
```
babeld
```
からリクエストを受け取り、
```
X-Stat
```
ヘッダーをパースし、ダウンストリームプロセスの環境を整えます。重要なのは、
```
gitrpcd
```
は独自の認証を行わないという点です。完全に
```
babeld
```
に信頼しており、
```
X-Stat
```
ヘッダー内のすべてのフィールドを権限ありと扱います。
pre-receive hook: プッシュが受け入れられる前にセキュリティポリシーを実行するコンパイルされた Go バイナリです。ファイルサイズ制限、ブランチ命名規則、LFS 整合性をチェックし、管理者定義のカスタムフックを実行します。

重要なリンク：X-Stat ヘッダー これらのコンポーネントをつなぐ重要なリンクが X-Stat ヘッダーです。これは、セミコロンで区切られた

key=value

ペアとしてセキュリティクリティカルなフィールドを運搬します。内部サービスはこのヘッダーをパースするために

で分割し、マップにデータを格納します。ここで重要な点：このマップには「後書きが優先（last-write-wins）」のセマンティクスが適用されます。もし某个キーが 2 回出現した場合、後方の値が静かに前方の値を上書きします。

babeld

がプッシュリクエストを転送する際、内部リクエストの一つには

X-Stat

ヘッダー内にプッシュオプションが含まれます。Git プッシュオプションはユーザーが

git push -o

で渡せる任意の文字列です。これはサーバーサイドへのヒントとして意図された標準的な git プロトコルの機能です。

babeld

はこれらを番号付きフィールド（

push_option_0

push_option_1

など）と

push_option_count

に沿ってエンコードします。

図：GitHub 内部 git push パイプライン

脆弱性：X-Stat フィールド注入

では、適切にサニタイズされずにユーザー制御入力（入力値）が X-Stat ヘッダーに到達すると何が起きるのでしょうか？

```
babeld
```
は git プッシュオプションの値をそのまま（サニタイズせず）X-Stat ヘッダーにコピーします。
```
;
```
が X-Stat フィールドの区切り文字であるため、プッシュオプションの値に含まれるセミコロンは、指定されたフィールドから抜け出し、攻撃者制御の新しいフィールドを作成してしまいます。
セミコロンが続いてセキュリティフィールド名が含まれるようなプッシュオプションの値を想像してください。
```
babeld
```
はこれをそのまま埋め込み、以下のようなヘッダーを生み出します：[malformed header example]。
```
;
```
で分割した際、このヘッダーは [parsed attacker controlled fields] としてパースされます。
攻撃者の値が優先されるのは、因为它がヘッダーのより後方に表示されるためです——last-write-wins。

我々はバイナリ分析とオンラインキャプチャ（生きている GHES インスタンスでのパケットキャプチャ）を通じてこれを確認しました。キャプチャには、正当な対応物とは別に注入されたフィールドが X-Stat ヘッダー上で出現し、それらを上書きしている様子が見られました。

逆符号解析された pre-receive バイナリとワイヤーレベル分析を組み合わせることで、注入可能な X-Stat フィールドのマッピングを行いました。特にセキュリティ関連性が高いのは以下の通りです：

フィールド	目的
`rails_env`	フック実行パスの制御（サンドボックス vs. 直接実行）
`custom_hooks_dir`	カスタムフックスクリプトの検索のベースディレクトリ
`repo_pre_receive_hooks`	実行する pre-receive フックの JSON 定義
`large_blob_rejection_enabled`	ファイルサイズ制限の実施
`reject_sha_like_refs`	SHA 類似なブランチ名のブロック
`user_operator_mode`	内部デバッグ出力の有効化

最初の 3 つが最も重要であり、これらによって遠隔コード実行 (RCE) が実現します。

RCE へのエスカレーション

large_blob_rejection_enabled

のようなセキュリティフラグを上書きすることは興味深いですし、真の質問は「フィールド注入をコード実行に変換できるか？」という点にあります。答えは上記の表からの 3 つのフィールド：

rails_env

custom_hooks_dir

, および

repo_pre_receive_hooks

にあります。なぜなのか理解するためには、pre-receive hook バイナリがカスタムフックをどのように処理するかを見ておく必要があります。

GHES は管理者定義のカスタム pre-receive フック——つまりプッシュが受け入れられる前に実行されるスクリプト——をサポートしています。pre-receive バイナリの逆符号解析を通じて、我々はそれが X-Stat ヘッダーからの

rails_env

フィールドから完全に制御される 2 つの実行パスを持つことを発見しました：

プダクション値でフックをサンドボックス内を実行するパス。
その他の値でフックを直接実行——サンドボックスもなく、アイソレーションもない——git サービスユーザーとしてファイルシステム完全アクセス権を持ちます。

これら 2 つのパスを分けている唯一のものは

rails_env

の値です。そして我々はこれを注入できます。

RCE へのエスカレーションは 3 つの注入を連鎖させます:

ステップ 1 – サンドボックスバイパス: 非プダクション値の
```
rails_env
```
を注入して、サンドボックス化されたプダクションパスから、非サンドボックス化されたパスへ移行します。
ステップ 2 – フックディレクトリのリダイレクト:
```
custom_hooks_dir
```
を注入し、バイナリがフックスクリプトを検索するベースディレクトリを制御します。
ステップ 3 – パス穿通を含むフック定義への注入:
```
repo_pre_receive_hooks
```
に、パス穿トランスフィージョンシーケンスを含む精巧なフックエントリで注入を行います。バイナリのパス解析は、攻撃者制御のベースディレクトリとトラバースペイロードを結合し、ファイルシステム上の任意のバイナリに解決します。

非プダクションパスでは、解決されたパスが直接実行されます——引数なし、サンドボックスなし——git サービスユーザーとして：

> [Unsandboxed code execution as the git user]

我々は GHES インスタンスに対して完全な制御を有しており、ファイルシステムの読み書きアクセス権と内部サービス構成への可視性を持っていました。

GHES から GitHub.com へ

GHES 上で RCE を達成しました。次に obvious な疑問——これは GitHub.com でも機能するのでしょうか？

我々は GitHub.com のリポジトリに対して同じ悪用連鎖を実行しました。プッシュは成功しましたが、カスタムフックは実行されませんでした。リモート出力なし、コード実行なし——何も起こりませんでした。

何が起きているかを理解するために、

user_operator_mode=bool:true

を注入して両プラットフォームでデバッグ出力を有効にし、出力を並べて比較しました。その結果、GitHub.com では GHES に見られる特定のフック実行ステップが欠落しており、カスタムフックコードパスが単に到達していないことが分かりました。

我々は再びバイナリに戻り、より深く調査しました。さらなる逆符号解析を通じて、X-Stat ヘッダーにおいてエンタープライズモードでサーバーが動作するかどうかを制御するブールフラグを特定しました。GHES ではこのフラグはデフォルトで true であるため、カスタムフックパスは常にアクティブです。一方、GitHub.com では false でデフォルトであり、通常条件下ではカスタムフックは決して到達しないことを意味します。

このフラグも X-Stat ヘッダー内で運搬されているため、同じメカニズムを通じて注入可能です。もう 1 つの注入されたフィールドと、GitHub.com での完全な悪用連鎖が機能しました。今回は

id:

の代わりに

hostname

を実行し、GitHub.com での RCE を確認しました。

クロステナントへの影響

GHES における RCE は重大な脆弱性です。一方、GitHub.com においては、同じ flaw が複数のユーザーおよび組織にサービスを提供する共有インフラストラクチャのせいでより広範な意味合いを持っていました。

GitHub.com はマルチテナントプラットフォームです。数百万の異なる組織とユーザーに属するリポジトリは、共有バックエンドインフラストラクチャ上に格納されています。我々が GitHub.com でコード実行を達成した際、git ユーザーとして動作する共有ストレージノードに着地しました。git ユーザーが存在する理由は、そのノード上ですべてのリポジトリ操作を提供するためです。設計上、このユーザーは該 node 上にホストされるすべてのリポジトリに対して広範なファイルシステムアクセス権を持っています。このユーザーを乗っ取ることは、組織や所有者に関わらず、node 上の任意のリポジトリを読み取れることを意味します。我々は 2 つの乗っ取られたノードからアクセス可能なリポジトリインデックスエントリを列挙し、それぞれで他者のユーザーおよび組織に属する数百万のエントリを発見しました。

明確に言っておきます：我々は他のテナントのリポジトリの内容にはアクセスしていませんでした。クロステナントへの曝露は、自らのテストアカウントのみを使用して検証し、git ユーザーのファイルシステムパーミッションが node 上の任意のリポジトリを読めばよいことを確認しました。

結論

単一の

git push

コマンドでさえ、GitHub の内部プロトコルの flaw を悪用し、バックエンドインフラストラクチャ上でコード実行を達成するのに十分でした。この脆弱性連鎖は GitHub のみを越えて広く拡張されるパターンを示しています。異なる言語で書かれた複数のサービスが共有内部プロトコルを通じてデータを渡す場合、各サービスがそのデータについて持つ仮定が批判的な攻撃面となります。このケースでは、1 つのサービスはプッシュオプション値を埋め込むことが安全であると仮定していました。別のサービスは、X-Stat ヘッダー内のすべてのフィールドが信頼されたソースによって設定されていると仮定していました。pre-receive フックは、環境変数がプダクション環境でしかプダクションではないと仮定しました。各仮定は孤立しては合理的でありましたが、組み合わせると危険となりました。

プダクションバイナリ内での非プダクションコードパスの存在、フックスクリプトへのパス穿通検証の欠如、および入力サニタイズなしでデリミタベースプロトコルの使用は、多くのコードベースに現れるパターンです。我々はマルチサービスアーキテクチャを構築するチームに対し、ユーザー制御入力が内部プロトコルを通じてどのように流れるかを監査することを推奨します——特にセキュリティクリティカルな構成が共有データフォーマットから派生する場合にこそです。

本研究は、AI 増強逆符号解析ツール——特に IDA MCP——のお陰が可能となりました。これにより、コンパイルされたバイナリを分析し、内部プロトコルを再構築することが、人手で行うには非現実的な速度で達成できました。これらのツールの成熟が進むにつれて、彼らが深くクロスコンポーネント分析を必要とする脆弱性情報クラスの発見においてますます重要な役割を果たすことを期待します。

責任ある開示タイムライン

2026-03-04: Wiz Research が X-Stat プッシュオプション注入脆弱性を発見。
2026-03-04: GHES 3.19.1 での RCE を確認。
2026-03-04: Wiz Research から GitHub へ脆弱性報告。
2026-03-04: GitHub が受領を確認。
2026-03-04: GitHub が GitHub.com で修正を配備。
2026-03-10: CVE-2026-3854 付与（CVSS 8.7）。
2026-03-10: GHES パッチリリース。
2026-04-28: 公開開示。

情報共有を続けます！

こんにちは！我々は Wiz Research チーム (@wiz_io) に所属する Sagi Tzadik (@sagitz_)、Nir Ohfeld (@nirohfeld)、Ronen Shustin (@ronenshh)、Hillai Ben-Sasson (@hillai)、Yuval Avrahami (@yuvalavra)、そして Noam Malron (@noamsec) です。我々はクラウドを誰もがより安全な場所にすることを単一の目標とするベテランホワイトハッカーのグループです。主にクラウドにおける新たな攻撃ベクトルの発見と、クラウドベンダーおよびサービスプロバイダーのアイソレーション問題の発掘に重点を置いています。我々は皆様からの声を心待ちしています！お気軽にお問い合わせください：X (Twitter) またはメール research@wiz.io まで。