タグアーカイブ GitHub

  1. ホーム   /  タグ付きの投稿: "GitHub"
git push操作でサーバー制御可能なRCE脆弱性 GitHubが2時間で修正完了
2026年5月4日 0

git push操作でサーバー制御可能なRCE脆弱性 GitHubが2時間で修正完了

2026年3月4日、GitHubはバグ報奨金プログラムを通じて極めて深刻な脆弱性の報告を受けた。対象はgit push 操作のパイプラインであり、悪用されるとGitHubのサーバー上で任意のコマンドを実行される可能性があった。GitHubは報告から2時間以内に修正を展開し、その後の調査で実際の悪用は一切なかったと結論づけている。

この脆弱性は、git push に付与できる --push-option で送った文字列が、サーバー内部で適切にサニタイズされずにメタデータへ挿入されることに起因する。攻撃者は細工したオプションを与えるだけで、本来信頼される内部フィールドを偽装し、サンドボックスを回避してコードを実行できた。

本記事では報告の経緯、脆弱性の仕組み、GitHubの対応と調査結果、そして多層防御の重要性について詳しく解説する。自社運用のGitHub Enterprise Serverを管理するエンジニアは、早急なアップデートが推奨されるため、最後の対応ポイントまで確認してほしい。

バグ報奨金プログラムからの報告と即時対応

バグ報奨金プログラムからの報告と即時対応

2026年3月4日、クラウドセキュリティ企業Wizの研究者らがGitHubのバグ報奨金プログラムにリモートコード実行（RCE）の脆弱性を報告した。この脆弱性は github.com だけでなく、GitHub Enterprise Cloud（データレジデンシーやEnterprise Managed Usersを含む）および GitHub Enterprise Server にも影響するものだった。

報告によれば、リポジトリへのプッシュ権限を持つユーザー（自身で作成したリポジトリを含む）であれば誰でも、単一の git push コマンドでサーバー上での任意コマンド実行が可能だった。攻撃に必要なのは、プッシュ時に指定する --push-option に細工した値を仕込むだけである。

検証から修正までのスピード

GitHubのセキュリティチームは報告を受け取ると直ちに検証を開始した。約40分で社内環境での再現に成功し、重大度を確認。その時点でUTC 17時45分、根本原因の特定と修正パッチの作成が始まった。そして同日19時（UTC）には github.com への修正展開が完了した。報告からわずか2時間弱での出来事だ。

この迅速な対応を可能にしたのは、詳細な再現手順と影響範囲が報告の段階で明確に示されていたことにある。Wizの研究者はプッシュオプションを経由したメタデータ汚染から環境偽装、サンドボックス回避に至る一連の攻撃チェーンを完全に解明していた。

脆弱性の仕組み git push オプションから任意コード実行まで

脆弱性の仕組み git push オプションから任意コード実行まで

ここでは攻撃手法の技術的な流れを整理する。核となるのは、GitHubの内部サービス間でプッシュメタデータをやり取りする際に使われる区切り文字と、ユーザー入力の不適切な扱いだ。

プッシュオプションが処理される流れ

git push には --push-option（または -o）というオプションがある。これはクライアントがサーバーに対してキーバリューペアの文字列を追加で送るための正当なGit機能だ。CI/CDパイプラインへのパラメータ渡しなどで利用される。

しかしGitHub内部では、このユーザー提供の値がそのままの形で内部プロトコルのメタデータに埋め込まれていた。メタデータには「リポジトリ種別」や「処理環境」などを指定するフィールドが含まれており、各フィールドは特定の区切り文字で分割される。

サニタイズ不足が引き起こす注入攻撃

問題は、この内部区切り文字として使われていた文字が、ユーザー入力にも含まれ得る点だった。攻撃者はプッシュオプションの値に区切り文字を混入させることで、メタデータを意図的に「延長」または「上書き」できた。

より具体的には、プッシュオプションに key=value;injected_field=malicious のような文字列を指定する。内部サービスはこの文字列を単一の値として扱うが、後段のサービスがメタデータをパースする際に、区切り文字 ; で新たなフィールドとして解釈してしまう。こうして下流のサービスは、攻撃者が注入したフィールドを「信頼された内部値」として処理する。

研究者はこの仕組みを連鎖的に利用し、プッシュが処理される環境を上書きし、通常は有効なサンドボックス制限を無効化した。最終的にサーバー上で任意のコマンドを実行するコードパスに到達する。

Before（修正前）
ユーザー送信: git push -o “repo_type=public;real_env=unsandboxed”
プッシュオプションの値に区切り文字 ; が含まれ、内部フィールドを偽装
内部メタデータに注入
“repo_type=public;real_env=unsandboxed” がそのまま連結され、パーサーが新たなフィールド「real_env」を解釈
結果: サンドボックス回避 → 任意コード実行
下流サービスが偽装された環境でプッシュを処理し、制限を突破
↓
After（修正後）
ユーザー送信: git push -o “repo_type=public;real_env=unsandboxed”
サニタイザーが区切り文字や危険なシーケンスを除去
内部メタデータは安全
“repo_type=public” のみが信頼できる値として処理され、注入されたフィールドは無視
結果: 通常のサンドボックス内でプッシュ処理
ユーザー入力は内部フィールドに影響を与えず、安全に実行
■ 修正前:区切り文字を悪用したフィールド注入が成立
■ 修正後:ユーザー入力がサニタイズされ、注入不可に

上図のように、ユーザーが指定したプッシュオプションが内部の区切り文字を経由してメタデータを汚染していた。修正後はサニタイズ処理が追加され、攻撃者が意図的にフィールドを延長できなくなっている。

脆弱性への修正と悪用調査

脆弱性への修正と悪用調査

github.com への緊急修正

2026年3月4日19時（UTC）、GitHubは github.com に修正を展開した。この修正により、プッシュオプションの値が内部メタデータのフィールド区切り文字を含まないよう適切にエスケープされる。以後、ユーザー入力が信頼された内部フィールドを上書きすることは不可能になった。

GitHub Enterprise Server 向けパッチとCVE

セルフホスト型の GitHub Enterprise Server (GHES) についても、同日中に全サポートバージョン向けのパッチが準備された。具体的には以下のリリース以降で修正が適用されている。

  • GHES 3.14.25 以降
  • GHES 3.15.20 以降
  • GHES 3.16.16 以降
  • GHES 3.17.13 以降
  • GHES 3.18.7 以降
  • GHES 3.19.4 以降
  • GHES 3.20.0 以降

この脆弱性には CVE-2026-3854 が割り当てられている。公開されたCVE情報は以下の通りだ。

  • CVE番号: CVE-2026-3854
  • 深刻度: Critical（緊急）
  • 影響範囲: 認証済みかつプッシュ権限を持つユーザーによるリモートコード実行

GitHubのCISOであるAlexis Wales氏は公式ブログで、GHESの全管理者に対し「直ちに最新のパッチリリースへアップグレードすることを強く推奨する」と呼びかけている。

悪用の有無を徹底調査

修正と並行して、GitHubは不正利用の痕跡がないかフォレンジック調査を開始した。この脆弱性には調査を容易にする特異な性質があった。悪用が成功した場合、サーバーは通常運用では決して通過しない特異なコードパスを必ず実行する。攻撃者がこれを回避することは構造上不可能である。

GitHubのエンジニアはこのコードパスにログ出力を仕込み、全テレメトリデータを解析した。その結果、以下の事実が確認された。

  • 該当コードパスが実行されたすべてのインスタンスは、Wizの研究者自身の検証作業と完全に一致した。
  • 他のユーザーやアカウントによる同コードパスの実行は一度も観測されなかった。
  • 顧客データへのアクセス、改ざん、持ち出しは一切発生しなかった。

これにより、github.com 上のリポジトリに対する実際の攻撃は一切なかったと結論づけられた。GHES環境についても、攻撃が成立するにはインスタンス上でプッシュ権限を持つ認証済みユーザーが必要であり、念のため /var/log/github-audit.log を確認し、プッシュオプションに ; を含む不審なログがないか点検することが推奨されている。

多層防御が生んだ追加の発見

多層防御が生んだ追加の発見

今回のインシデント対応の中で、インプットサニタイズの修正に加えて、防衛の階層化に関わるもう一つの重要な知見が得られた。攻撃が成立した理由の一部は、サーバー上に「その環境では本来不要なはずのコードパス」が存在していたことにある。

具体的には、コンテナイメージのディスク上に、異なる製品構成でのみ使われる想定のコードが含まれていた。過去のデプロイ手法ではこのコードが正しく除外されていたが、デプロイモデルの変更時にその除外ルールが引き継がれなかったのだ。

GitHubはこの不要なコードパスを、当該環境から完全に削除した。たとえ将来同種の注入脆弱性が発見されたとしても、攻撃者の行動範囲を大幅に制限できるようになっている。

このケースは、多層防御（Defense in Depth）が単なる標語ではないことを改めて示している。入力検証という第一の防衛線だけでなく、不必要なコンポーネントの除去という第二の防衛線が被害の拡大を防ぐ鍵になる。

ユーザーが今すぐ取るべき対応

ユーザーが今すぐ取るべき対応

GitHub.com および GitHub Enterprise Cloud ユーザー

github.com、GitHub Enterprise Cloud（Enterprise Managed UsersやData Residencyを含む）の環境は、2026年3月4日の時点で修正済みだ。これらのサービスを利用しているユーザー側での特別な対応は不要である。

GitHub Enterprise Server 管理者

セルフホスト環境では、先述のパッチバージョンへのアップグレードが不可欠だ。さらに、念のため監査ログを確認しておくとよい。具体的には /var/log/github-audit.log を対象に、プッシュオプションにセミコロン（;）を含むプッシュ操作が記録されていないか調査する。

攻撃の成立には認証済みのプッシュ権限が必要なため、内部不正やアカウント乗っ取りのリスクも考慮し、不審なアクティビティがないか定期的に確認することが望ましい。

この記事のポイント

  • git push に付与する –push-option のサニタイズ不足が、内部メタデータへのフィールド注入を許しリモートコード実行に繋がった
  • GitHubは報告から2時間以内に修正を展開し、サーバーログの解析で悪用の形跡がないことを確認した
  • GitHub Enterprise Server 環境では、指定のパッチバージョンへの即時アップグレードが強く推奨される
  • 入力サニタイズに加え、不要なコードパスを除去する多層防御の重要性が改めて浮き彫りになった
海田 洋祐
, , , , , ,
AI・開発支援

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.