GitHubのプッシュオプション注入の脆弱性CVE-2026-3854
- カテゴリ
- 脆弱性の公表
GitHubの2026年4月28日の発表によると、リポジトリへのプッシュ権限を持つ利用者が、細工したプッシュオプションを付けたgit pushの1コマンドで、GitHubのサーバー上で任意のコマンドを実行できた［1］。GitHubは調査で悪用は無かったと結論づけた［1］。Wizは同じ日に、執筆時の同社のデータではGitHub Enterprise Server（GHES）のインスタンスの88%がまだ脆弱だとした［9］。
脆弱性の内容
| 項目 | 値 | 資料 |
|---|---|---|
| CVE | CVE-2026-3854 | ［6］ |
| CVSS v4.0（GitHub） | 8.7（HIGH） | ［6］ |
| CVSS v3.1（NVD） | 8.8 | ［7］ |
| CWE | CWE-77（コマンドインジェクション） | ［6］ |
| リリースノートの重要度 | HIGH | ［2、3、4］ |
区切り文字による注入
GitHubの公式ブログの記事によると、プッシュの処理は複数の内部サービスを通り、リポジトリの種類や処理する環境などのメタデータが内部のプロトコルでサービス間に渡される［1］。プッシュオプションは、プッシュの際にクライアントがサーバーへキーと値の文字列を送るgitの機能である［1］。利用者が与えた値は十分に無害化されないまま内部のメタデータに組み込まれ、その形式は利用者の入力にも現れうる区切り文字を使っていた［1］。このため攻撃者は、下流のサービスが信頼された内部の値と解釈するフィールドを注入できた［1］。
GitHubは、研究者が注入した複数の値をつなげ、プッシュを処理する環境の上書きと、フックの実行を制限するサンドボックスの回避を経て、サーバー上で任意のコマンドを実行できることを示したと説明した［1］。攻撃に使えるリポジトリには、利用者が自分で作ったものも含まれる［1］。この発見には、GitHubのバグバウンティの歴史で最高額の報奨の一つを出すとした［1］。
GitHubの4月28日の記事では、悪用が成立した一因は、サーバーが稼働する環境向けではないコードパスにアクセスできたことだった［1］。このコードパスは別の製品構成でだけ使うものだったが、サーバーのコンテナイメージの一部としてディスク上にあった［1］。以前の展開方法はこのコードを正しく除外していたが、展開のモデルが変わったときに除外が引き継がれなかった［1］。
Wizが示した攻撃の手順
Wizの4月28日の報告では、IDA MCPを使った自動のリバースエンジニアリングなど、AIで補った道具でGitHubのコンパイル済みのバイナリを解析し、内部のプロトコルを再構成した［9］。Wizは、これがクローズドソースのバイナリでAIを使って見つけた最初の重大な脆弱性の一つだとした［9］。
SSHでのgit pushは、全git操作の入口となるgitのプロキシのbabeld、認証サービスのgitauth、内部RPCサーバーのgitrpcd、ポリシーを適用するGoのバイナリのpre-receiveフックを通る［9］。gitrpcdは自ら認証を行わずにbabeldを完全に信頼し、X-Statヘッダーの全フィールドを正当なものとして扱う［9］。X-Statヘッダーは、セキュリティ上重要なフィールドをセミコロン区切りのkey=valueの組で運ぶ［9］。内部サービスはこれを「;」で分割してmapにし、同じキーが2回現れると後の値が前の値を黙って上書きする［9］。
babeldは、プッシュオプション（git push -o）の値をpush_option_0などの番号付きのフィールドとしてX-Statヘッダーに写し、セミコロンを無害化していなかった［9］。Wizは、バイナリの解析と稼働中のGHESのパケットキャプチャの両方で、注入したフィールドが正規のフィールドを上書きすることを確かめた［9］。注入できるセキュリティ上重要なフィールドとして、Wizはrails_env・custom_hooks_dir・repo_pre_receive_hooks・large_blob_rejection_enabled・reject_sha_like_refs・user_operator_modeを挙げ、最初の3つが遠隔コード実行につながるとした［9］。
pre-receiveのバイナリには、rails_envの値だけで分かれる2つの実行経路がある［9］。本番の値ではフックをサンドボックス内で実行し、それ以外の値ではgitのサービスユーザーとしてサンドボックスなしで直接実行する［9］。Wizの遠隔コード実行は、3つの注入をつないだものだった［9］。
- 本番以外のrails_envの値で、サンドボックスを回避する［9］
- custom_hooks_dirで、フックを探す基準のディレクトリを変える［9］
- パストラバーサルを含むフックの定義を、repo_pre_receive_hooksに注入する［9］
Wizは、GHESではサンドボックスの外でgitユーザーとしてコードを実行し、ファイルシステムの読み書きを含めてインスタンスを完全に制御できたと報告した［9］。GitHub.comでは、同じ手順でカスタムフックが実行されなかった［9］。エンタープライズモードを決める真偽値のフラグはGHESではtrue、GitHub.comではfalseが既定で、このフラグもX-Statヘッダーにあって同じ仕組みで注入できた［9］。もう1つのフィールドを注入すると、GitHub.comでも全手順が成立した［9］。
テナントをまたぐ露出
Wizの報告によると、GitHub.comでコード実行に至った先は、gitユーザーで動く共有ストレージノードだった［9］。gitユーザーはノード上の全リポジトリに広いファイルシステムのアクセス権を持つ［9］。Wizは侵害した2つのノードからリポジトリの索引の項目を列挙し、それぞれで他の利用者・組織に属する数百万の項目を見つけた［9］。
Wizは、他のテナントのリポジトリの内容にはアクセスせず、テナントをまたぐ露出は自社の試験用アカウントだけで確かめたと説明した［9］。GHESでは、同じ脆弱性でホストする全リポジトリと内部の秘密情報を含むサーバー全体の侵害に至るとした［9］。
時系列
| 日付 | 主体 | 内容 | 資料 |
|---|---|---|---|
| 2026年 | Wiz | 脆弱性を発見し、GHES 3.19.1で遠隔コード実行を確かめ、GitHubに報告した | ［9］ |
| 2026年 | GitHub | バグバウンティで報告を受け、40分以内に社内で再現して深刻度を確かめた | ［1］ |
| 2026年 | GitHub | 根本原因を特定した（時刻はUTC） | ［1］ |
| 2026年 | GitHub | github.comに修正を展開した（時刻はUTC） | ［1］ |
| 2026年 | - | CVE-2026-3854が予約された | ［6］ |
| 2026年 | GitHub | GHES 3.14.24・3.18.6・3.19.3をリリースした | ［2、3、4］ |
| 2026年 | GitHub | CNAとしてCVE記録を公開した（時刻はUTC） | ［6］ |
| 2026年 | GitHub | GHES 3.14.25・3.18.7・3.19.4をリリースした | ［2、3、4］ |
| 2026年 | NVD | CVSS v3.1の基本値を付けた | ［8］ |
| 2026年 | GitHub | 3.14.24・3.18.6・3.19.3の公開の取り下げをリリースノートに記した | ［2、3、4］ |
| 2026年 | GitHub | GHES 3.20.0をリリースした | ［5］ |
| 2026年 | GitHub | CVE記録の参照を3.14.25などの版のリリースノートに差し替え、説明を改めた | ［8］ |
| 2026年 | GitHub | 公式ブログで経緯を公表した | ［1］ |
| 2026年 | Wiz | 技術的な詳細を公表した | ［9］ |
| 2026年 | CISA-ADP | CVE記録にSSVCの評価を加え、参照にWizの記事を加えた | ［6、8］ |
対象の製品と版
| 製品 | 影響を受ける版 | 修正版 | 資料 |
|---|---|---|---|
| GHES 3.14 | 3.14.0〜3.14.24 | 3.14.25 | ［6］ |
| GHES 3.15 | 3.15.0〜3.15.19 | 3.15.20 | ［6］ |
| GHES 3.16 | 3.16.0〜3.16.15 | 3.16.16 | ［6］ |
| GHES 3.17 | 3.17.0〜3.17.12 | 3.17.13 | ［6］ |
| GHES 3.18 | 3.18.0〜3.18.6 | 3.18.7 | ［6］ |
| GHES 3.19 | 3.19.0〜3.19.3 | 3.19.4 | ［6］ |
| GHES 3.20 | - | 3.20.0 | ［1］ |
GitHubは、GHESでの悪用には、そのインスタンスでプッシュ権限を持つ認証済みの利用者が要るとした［1］。
悪用の状況
GitHubの説明では、悪用はgithub.comの通常の運用で使われないコードパスをサーバーに通らせる［1］。これは注入の仕組みに伴う性質で、攻撃者は避けることも抑えることもできない［1］。GitHubはこのコードパスを記録し、テレメトリでその実行を照会した［1］。該当した実行はすべてWizの研究者自身の試験によるもので、ほかの利用者・アカウントはこのコードパスを起こしていなかった［1］。
GitHubは、この脆弱性によって顧客データがアクセス・改変・持ち出しされたことは無かったとした［1］。CVE記録でCISA-ADPが付けたSSVCの評価は、Exploitationがnone、Automatableがno、Technical Impactがtotalである［6］。
| 種別 | 値 | 示した組織 | 資料 |
|---|---|---|---|
| GHESの監査ログの記録 | /var/log/github-audit.logで、プッシュオプションに「;」を含むプッシュ操作 | GitHub | ［1］ |
修正と回避策
GitHubは、2時間足らずで報告の内容を確かめ、github.comに修正を展開し、フォレンジック調査を始めたと説明した〔注1〕［1］。修正は、利用者が与えたプッシュオプションの値を適切に無害化し、内部のメタデータのフィールドに影響できないようにするものだった［1］。入力の無害化を主な対策とし、不要なコードパスをあるべきでない環境から除いた［1］。同様の注入の脆弱性が将来見つかっても、この追加の強化で攻撃者のできることが限られるとした［1］。
github.com・GitHub Enterprise Cloud・GitHub Enterprise Cloud with Enterprise Managed Users・GitHub Enterprise Cloud with Data Residencyの利用者に、GitHubは対応は要らないとした［1］。GHESの利用者には、直ちに更新するよう強く勧めた［1］。
GitHub Docsのリリースノートによると、3.14.24はコンテナ間のGitの版の不一致により公開を取り下げられた［3］。3.18.6と3.19.3は、運用上の理由で取り下げられた［2、4］。GitHubは、各系列の最新のパッチリリースを使うよう案内した〔注2〕［2、3、4］。
未公表の事項
- GHESのインスタンスでの悪用の有無
- 報奨金の額
- Wizが示した88%の母数と算出の方法
- 3月10日にリリースし、後に取り下げた版での修正の有効性
注
出典
当事者
- ［1］GitHub, Inc.『Securing the git push pipeline: Responding to a critical remote code execution vulnerability』（2026年4月28日公開、2026年4月29日更新）
- ［2］GitHub, Inc.『Enterprise Server 3.19 release notes』（2026年3月10日公開、2026年3月13日更新）
- ［3］GitHub, Inc.『Enterprise Server 3.14 release notes』（2026年3月10日公開、2026年3月13日更新）
- ［4］GitHub, Inc.『Enterprise Server 3.18 release notes』（2026年3月10日公開、2026年3月13日更新）
- ［5］GitHub, Inc.『Enterprise Server 3.20 release notes』（2026年3月17日公開）
公的機関
- ［6］CVE Program『CVE-2026-3854: Remote code execution via git push option injection in GitHub Enterprise Server』（2026年3月10日公開、2026年4月29日更新）
- ［7］National Institute of Standards and Technology『CVE-2026-3854』（2026年3月10日公開、2026年6月17日更新）
- ［8］National Institute of Standards and Technology『CVE Change History: CVE-2026-3854』（2026年3月10日公開、2026年6月17日更新）
調査・観測
更新記録
- 2026年5月3日：公開した。
- 2026年6月17日：National Institute of Standards and TechnologyのNVDの記録と変更履歴の6月17日の更新版（出典7、8）を加え、「脆弱性の内容」と「時系列」を改めた。