GitHub RCE脆弱性 CVE-2026-3854 の詳細解説

· security devtools · Source ↗

まとめ

  • Wiz Research が GitHub の X-Stat ヘッダープロトコルに CVSS 8.7 のインジェクション欠陥を発見。認証済みユーザーなら誰でも、git push 一回で GitHub.com および GHES に RCE を実行できる。

重要ポイント

  • 根本原因: babeld が git push オプションの値（ユーザー制御の文字列）をセミコロン区切りの X-Stat ヘッダーにコピーする際、セミコロンをサニタイズしていない。これにより「最後に書いた値が勝つ」セマンティクスを利用したフィールドインジェクションが可能になる。
  • 3つのフィールドインジェクションを連鎖させることで RCE を達成: rails_env を上書きしてサンドボックスを無効化 → custom_hooks_dir をリダイレクト → repo_pre_receive_hooks でパストラバーサルし、git サービスユーザーとして任意バイナリを実行。
  • GitHub.com では追加の注入フィールド（enterprise_mode フラグ）でカスタムフックパスが解放され、数百万件のパブリック・プライベートリポジトリのファイルシステムへアクセスできる共有ストレージノードで RCE が成立した。
  • GitHub.com は報告から 6 時間以内にパッチ適用済み。GHES はバージョン 3.14 以降向けのパッチが提供されているが、3.19.3 が 3月10日にリリースされてから 7 週間後時点で、セルフホスト環境の 88% が未適用のままだった。
  • Wiz は IDA MCP を用いた AI 補助リバースエンジニアリングにより、クローズドソースの GHES バイナリを大規模に解析。ブラックボックスのコンパイル済みバイナリからこの手法で発見された初の重大 CVE の一つとして位置づけられている。

Hacker News コメントのまとめ

  • 「88% が未パッチ」という数字は CVE 本体よりも大きな衝撃を与えた。パッチは 3月10日にリリース、開示は 4月28日であり、ほとんどの GHES 運用者が重大な RCE を抱えたまま約 2 ヶ月間放置していたことになる。
  • GitHub の優位性への影響については意見が割れた。「GitHub 支配の終わりを示す悪いシグナル」と読む声がある一方、「移行先の代替製品もセキュリティ実績が同等か不明であり、乗り換えには未知のリスクが伴う」という反論もあった。

注目コメント

  • @bananapub: パッチ 3月10日リリース、開示 4月28日 ―― 「オンプレミスの顧客の 88% が 7 週間前の重大なセキュリティ修正を適用していない。それは……まずい。」
  • @latchkey: セルフホスト代替製品への移行も同等かそれ以上のリスクを伴う。GHES からの移行を検討しているチームにとって、明確に安全な移行先は存在しないと主張。

原文 | HN で議論する

英語版: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown · Original source

あわせて読みたい