ブロック状の幾何学パターンの中央に盾とチェックマークが浮かぶセキュリティのイメージ

Article

GitHubが`git push`パイプラインのCriticalなRCE脆弱性「CVE-2026-3854」を開示、報告から修正まで1時間15分で完了

GitHubは2026年4月28日、`git push`のpush optionsを介した認証済みユーザーによるリモートコード実行（CVE-2026-3854）の事後分析記事を公開しました。Wizから報告を受けた2026年3月4日17:45 UTCから、内部での再現確認を経て19:00 UTCにgithub.comへ修正を展開するまでが約1時間15分。GitHub Enterprise Server向けには複数バージョンのパッチも同時提供されています。

This article is not published in this language yet, so the Japanese version is shown instead.

`git push`のpush optionsから抜けたCriticalなRCE

GitHubは2026年4月28日付（4月29日に更新）で、The GitHub Blog上に「Securing the git push pipeline: Responding to a critical remote code execution vulnerability」と題する事後分析記事を公開しました。対象の脆弱性はCVE-2026-3854で、深刻度はCriticalとして扱われています。

問題の経路はGitのgit push --push-optionフローでした。GitHubの説明によれば、プッシュ権限を持つ認証済みユーザーが、特定の区切り文字を含む細工したpush optionsを送ると、入力検証を回り込んで内部メタデータに値を埋め込むことができ、結果としてサーバー側でのコード実行につながる経路があったとのことです。記事は**「The exploit forces the server to take a code path that is never used during normal operations on github.com.」**と書いており、通常のpushでは絶対に通らないコードパスをエクスプロイトが強制的に呼び出していたことが説明されています。

GitHubのセキュリティを象徴する盾とブロック状の幾何学パターンのイラスト

画像引用元: GitHub Blog

タイムライン：受領から本番反映まで1時間15分

事後分析の中で目を引くのは、インシデント対応のタイムラインの短さです。

時刻（UTC）	出来事
2026年3月4日 17:45	WizからGitHubのBug Bountyプログラム経由で報告
約40分後	内部での再現確認・検証完了
2026年3月4日 19:00	github.comへの修正反映完了（受領から約1時間15分）

報告から本番展開までを1時間15分で締めた背景として、記事は内部のセキュリティパイプラインが**「再現→修正→デプロイ」を分離可能なステージで自動化していたことを強調しています。Critical級の脆弱性を、git pushのような全ユーザーが日常的に叩く経路**で踏んでも、横展開の時間を最小化できた事例として参考になります。

なお報告者は脅威リサーチ企業のWizで、GitHubは公式にクレジットを記載しています。Bug Bountyによる外部発見が、結果的にCriticalインシデントを最短で塞いだ典型例とも言えます。

影響範囲：Cloud／Cloud with Data Residency／EMU／GHESまで

修正対象として明示されているのは次の系統です。

github.com
GitHub Enterprise Cloud
GitHub Enterprise Cloud with Data Residency
GitHub Enterprise Cloud with Enterprise Managed Users
GitHub Enterprise Server（全サポートバージョン）

クラウド版についてはGitHub側で透明的に修正が反映されており、利用者側の作業は不要です。ただしGitHubは**「No other users or accounts triggered this code path. No customer data was accessed, modified, or exfiltrated.」と記しており、影響を受けたとみられるアクティビティは報告者の検証以外には観測されていない**としています。一次的な実害は確認されなかった、という結論です。

問題はGitHub Enterprise Server（GHES）です。こちらはオンプレ運用のため、ユーザー組織自身がパッチを当てる必要があります。記事は対象パッチバージョンとして3.14.25以降／3.15.20以降／3.16.16以降／3.17.13以降／3.18.7以降／3.19.4以降／3.20.0以降を挙げています。

GHES運用者がやるべきこと：監査ログのチェックとアップグレード

GHESを運用している組織には、記事内で2つの対応が要求されています。

/var/log/github-audit.logを確認し、push optionsに;が含まれるpush操作の有無をチェックする
上記の対象バージョン以上に速やかにアップグレードする

加えて、push optionsを実装で利用している場合は、;を含む値を正規入力としては想定しないことを上流で明示しておくと、追加の防御ラインになります。CIや内製ツールでgit push --push-option ...を多用している組織は、生成側のサニタイズも見直す価値があります。

ログ確認と並行して、過去90日程度のpush権限保有者の棚卸しもこの機会に進めておきたいところです。今回のRCEは「プッシュ権限を持つ認証済みユーザー」が攻撃者になり得る前提だったため、書き込み権限の最小化は将来同種の問題が出たときにも効きます。

教訓：プロトコル拡張点と「めったに通らないコードパス」

push optionsは本来、サーバーフックに任意のメタデータを渡すGitプロトコルの拡張点で、CIゲーティングやポリシーチェックに使われている機能です。「拡張点」を提供する以上、入力経路が増え、通常運用ではほぼ呼び出されないが攻撃面としては開いているコードパスが生まれやすいのは構造的な事実です。GitHubが事後分析を経路の特性そのものに焦点を当てて公開したのは、後続のサービスやセルフホスト型のGitホスティング、CI／CDツールにとっての横展開の手がかりになります。

報告から1時間15分で本番反映できた点は、内部のリリースパイプラインがCriticalパッチをロックダウンしてでも通せる構造になっていたことを示します。同じ業種で類似のサービスを提供する事業者にとっては、**「夜間や休日に当てる用のhotfix経路」**を整備しているか、外部報告者からの一次連絡からデプロイまでの導線が誰でも踏めるかを改めて点検する材料になりそうです。