GitHub Enterprise Server の脆弱性 CVE-2026-3854 が FIX：RCE と完全なサーバ侵害

Critical GitHub.com and Enterprise Server RCE Vulnerability Enables Full Server Compromise

2026/04/28 CyberSecurityNews — GitHub の内部 git インフラにおいて、深刻なリモート・コード実行 (RCE) 脆弱性 CVE-2026-3854 が Wiz の研究者により発見された。この脆弱性を悪用する認証済みユーザーは、バックエンド・サーバを侵害して数百万のプライベート・リポジトリへアクセスし、GitHub Enterprise Server (GHES) 環境では完全なサーバ乗っ取りが可能となる。

AI を活用したリバース・エンジニアリングで、クローズド・ソースのコンパイル済みバイナリを解析した結果として、この脆弱性は発見された。根本的な原因が、GitHub の内部 babeld git プロキシにおけるプッシュ・オプション値の処理時に、特殊要素の不適切なサニタイズ (CWE-77) が発生していることも判明した。

ユーザーが “git push -o” を実行すると、任意のオプション文字列がサーバへ送信されるが、この脆弱性により babeld がセミコロンをサニタイズしないという状況が発生する。したがって、フィールド区切り文字であるセミコロンを含むサニタイズされていない値が、内部 X-Stat ヘッダへとコピーされてしまう。このヘッダでは、セミコロンがフィールド区切り文字として機能する仕様となっている。

下流サービスである gitrpcd は、X-Stat ヘッダをラスト・ライト・ウィン (Last-Write-Win) で解析するため、攻撃者はプッシュ・オプション内にセミコロン／任意のフィールド名／任意のフィールド値を埋め込むことで、新たな key-value フィールドを注入できる。これにより、 rails_env／custom_hooks_dir／repo_pre_receive_hooks といった重要なセキュリティ・フィールドが、単一のインジェクション・ベクターにより上書き可能となる。

RCE への権限昇格手法

RCE への権限昇格には、以下の 3 つのフィールド注入の連鎖が必要である。

• sandbox 回避：非 production の rails_env を注入することで、pre-receive hook の実行パスを sandbox 経路から非 sandbox の直接実行へと切り替える。
• hook ディレクトリのリダイレクト：custom_hooks_dir を上書きすることで、hook スクリプトの探索パスをリダイレクトする。
• パス・トラバーサルによる不正処理：repo_pre_receive_hooks に パス・トラバーサル・ペイロードを注入することで、任意のバイナリをファイル・システム上から解決し、git サービス・ユーザーとして直接実行させる。

このエクスプロイトは権限昇格を必要とせず、特別なツールやゼロデイにも依存しない。標準的な git クライアントのみで成立する。

影響範囲

影響範囲として、GitHub Enterprise Server では、すべてのリポジトリおよび内部シークレットへの不正な Read／Write アクセスが生じ、完全なサーバ侵害が可能となる。GitHub.com では、当初 custom hook 経路はデフォルトで無効であったが、X-Stat ヘッダ内の enterprise_mode フラグの注入が可能であることが判明した。その結果、シェアード・インフラ上でも同一のエクスプロイト・チェーンが成立した。

シェアード・ストレージ・ノードで RCE が達成されると、git サービス・ユーザーは、同一ノード上の他のユーザー／組織に属する数百万のリポジトリに対してファイル・システム・レベルでアクセス可能となる。Wiz の研究者たちは、サードパーティ・データにはアクセスせず、自身のテスト・アカウントのみを用いてクロス・テナントへの影響を検証した。

AI による脆弱性研究の転換点

このインシデントは、クローズド・ソース・バイナリの深刻な脆弱性を、AI ツールの活用により発見できることを示す、代表的な一例である。Wiz は IDA MCP を活用してリバース・エンジニアリングを自動化し、コンパイル済みバイナリ間における GitHub の内部プロトコルを迅速に再構築した。この解析は、手動では極めて困難であり、多大な時間を要するものである。

対応状況と対策

この事例は、複雑なマルチ・サービス・アーキテクチャにおける、脆弱性研究手法の転換点を示す。GitHub は 2026年3月4日に報告を受領し、数時間以内に検証を実施した。その結果、同日の UTC 19:00 までに GitHub.com へ修正を適用しており、対応は約 6 時間以内に完了した。フォレンジック調査の結果、公開前の悪用は確認されていない。

すでに、GitHub Enterprise Server 向けにパッチが提供されているため、管理者は直ちに対応する必要がある。

• 影響バージョン：3.19.1 以下
• 修正バージョン：3.19.4／3.20.0
• 旧バージョンに対する修正：3.14.25／3.15.20／3.16.16／3.17.13／3.18.8

情報が公開された時点の Wiz のデータによると、GHES インスタンスの 88% が未修正の状態である。

GitHub Enterprise Cloud および GitHub.com のユーザーは対応不要である。

GHES 管理者は “/var/log/github-audit.log” を監査し、プッシュ・オプションにおいて異常な特殊文字を含む操作が行われていないことを確認すべきである。この指標を用いることで、過去におけるエクスプロイト試行を特定できる。

訳者後書：GitHub における脆弱性 CVE-2026-3854 は、内部プロキシにおける入力値に対する不十分な処理に起因します。ユーザーが送信したコマンドのオプションに、区切り文字であるセミコロンが含まれていても、そのまま受け入れてしまうことで、意図しないデータが後続のシステムへ送り込まれます。その結果、本来は変更できないはずの設定が書き換えられ、最終的にはリモートでのコード実行につながるという深刻な仕組みになっています。ご利用のチームは、ご注意ください。よろしければ、GitHub で検索も、ご利用ください。