ハクソク

世界を動かす技術を、日本語で。

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

9時間前原文(www.wiz.io)

概要

  • Wiz ResearchがGitHubの内部gitインフラに重大な脆弱性（CVE-2026-3854）を発見
  • 認証済みユーザーが標準gitクライアントのみでサーバー上で任意コマンド実行可能
  • GitHub.comとGitHub Enterprise Server両方が影響、特にGHESは完全なサーバー乗っ取りが可能
  • GitHub.comは6時間以内に修正、GHESは即時アップグレード推奨
  • AIを活用したバイナリ解析により発見、今後の脆弱性調査の新たな潮流を示唆

GitHub内部gitインフラにおける重大脆弱性（CVE-2026-3854）概要

  • Wiz ResearchがGitHubの内部gitインフラにおける危険な脆弱性を発見

  • CVE-2026-3854は、認証済みユーザーが単一のgit pushコマンドでGitHubのバックエンドサーバー上で任意コマンド実行可能

  • 標準のgitクライアントのみで攻撃が成立する容易なエクスプロイト性

  • GitHub.comでは共有ストレージノード上でのリモートコード実行（RCE）が可能

  • **GitHub Enterprise Server（GHES）**ではサーバー完全乗っ取り、全リポジトリや内部シークレットへのアクセスが可能

    • 数百万件のパブリック・プライベートリポジトリが影響範囲
    • クロステナント影響も確認

  • GitHubは6時間以内にGitHub.comを修正し、GHES向けにはパッチを公開

  • GHES利用者は直ちに3.19.3以降へのアップグレードが必須

  • Wizによる詳細な技術解説と修正手順はGitHub公式セキュリティブログに掲載

技術的詳細と攻撃手法

  • GitHub内部のgit push処理パイプラインは複数のサービスで構成

    • babeld：エントリポイント兼gitプロキシ、認証情報の受け渡し
    • gitauth：認証・権限確認・セッションごとのセキュリティポリシー返却
    • gitrpcd：内部RPCサーバー、X-Statヘッダーを解析
    • pre-receive hook：Go製バイナリ、セキュリティポリシーの強制

  • 重要な連携はX-Statヘッダーで実現

    • セミコロン区切りのkey=value形式、同一キーは後勝ち（last-write-wins）
    • push option値がサニタイズされずにX-Statヘッダーへコピーされる設計ミス
    • 任意のセミコロン挿入で新たなフィールドを攻撃者が注入可能

  • 特に危険なフィールド

    • rails_env：hook実行パス（サンドボックス or 直実行）の切り替え
    • custom_hooks_dir：カスタムフックスクリプトのベースディレクトリ
    • repo_pre_receive_hooks：実行するpre-receive hookの定義

  • エスカレーション手順

    • rails_envを非production値に注入→サンドボックス回避
    • custom_hooks_dirで任意ディレクトリ指定
    • repo_pre_receive_hooksでパストラバーサル付き定義を注入
    • 任意バイナリをgitユーザー権限でサンドボックス外実行

  • GitHub.comでは初期状態でカスタムフック実行が無効化（enterpriseモードフラグがfalse）

    • しかし、このフラグもX-Statヘッダー経由で注入可能
    • 最終的にGitHub.comでもRCE成立を確認

影響範囲・リスク

  • GHES：サーバー完全乗っ取り、全リポジトリ・内部情報の漏洩リスク
  • GitHub.com：共有ノード上のクロステナントアクセス
    • gitユーザーの権限で他組織・他ユーザーのリポジトリ読み取り可能
    • Wizは自社テストアカウントのみで検証、実際の他者データアクセスは未実施

必要な対応・推奨事項

  • GitHub.com利用者：追加対応不要（既に修正済み）
  • GHES利用者：
    • 直ちに3.19.3以降へアップグレード
    • 脆弱性のあるバージョン：<= 3.19.1, 3.14.2, 3.15.19, 3.16.15, 3.17.12, 3.18.6
    • Wiz Threat Centerのクエリで脆弱なGHESインスタンスの特定が可能

AI活用による調査と今後の展望

  • WizはAI支援リバースエンジニアリング（IDA MCP利用）により調査を自動化
  • 従来は困難だったブラックボックスバイナリ解析も効率化
  • AIが脆弱性発見の新たな潮流となる可能性
  • GitHubはWizの協力と専門性を高く評価、バグバウンティ最高クラスの報奨を授与

まとめと今後の教訓

  • GitHubのような多層・多言語サービス連携では、入力値の信頼性・一貫性が極めて重要
  • サービス間のデータ受け渡しにおけるサニタイズ不足が深刻な脆弱性に直結
  • AIを活用した自動解析・バグハンティングの重要性増大
  • 継続的な研究者・プラットフォーマー間の協力がセキュリティ向上の鍵

Hackerたちの意見

みんなGitHubを置き換えたいって言うけど、何で？今になってRCEが出てるのに、他のサービスが大丈夫だって思う人いる？
└
GitLab？
└
.... git？それをgitに置き換えればいいよ。全体のUIが欲しいなら、Forgejoみたいな機能が少なくて問題が起きにくいものを使えばいい。
└
今は、自分の内部用のプロジェクト（例えば、ansibleスクリプト）と一般向けに使える可能性のあるプロジェクトをはっきり分けている。前者はプライベートなForgejoインスタンスでホストしてる。後者はGitHubに置くけど、Forgejoインスタンスにもミラーするつもり。Forgejoが実際には単一のバイナリで、比較的簡単に設定できることに驚いた。内部サービスは全部Forgejoインスタンスを参照してるから、GitHubから逃げる必要があっても、負担が少ないんだ。
└
「合理的」な答えは、主要な自己ホストのForgejoインスタンスを基準にして、GitHubはそのミラーとして無料のCIを利用するためだけに使うって感じかな。それが続く限り、秘密情報は専用のホスティングプロバイダーに預ける（最近のおすすめのプロバイダーは知らないけど）。
└
ただのgit
└
VPNの背後にあるセルフホストのGitLab。オールインワンのDockerイメージといくつかのGitLabランナーがあれば、小規模から中規模のチームには十分です。（本当に必要でない限り、Kubernetesバージョンで複雑にしない方がいいよ）
> 2026年4月28日 > GitHub Enterprise Serverの顧客はすぐにアップグレードすべきです - 現在のデータによると、88%のインスタンスがまだ脆弱です > GHESバージョン3.19.3以上にアップグレードしてください https://docs.github.com/en/enterprise-server@3.19/admin/rele... : > Enterprise Server 3.19.3 - 2026年3月10日 88%のオンプレミス顧客が7週間前の重要なセキュリティ修正を適用していないって、これは…やばいね。
└
問題は、大規模なインストールでのアップグレードプロセスがどれだけ脆弱かってこと。大きなデータを扱う他のエンタープライズソフトウェアでは、ちょっとしたことでインストールが壊れて、運用チームがロールバックする羽目になったことがある。昔のSharePointみたいで、アップグレードするのは賭けみたいなもんだった。
└
エンタープライズにいると、通常のスケジュール外で何かを更新してすべてをぶっ壊す（そして責められる）か、スケジュールに従って最善を期待するかのどちらかだね。どっちが選ばれるか、わかるよね…
└
これらのオンプレミスの顧客は、GHESインスタンスへのアクセスを企業のVPNなどの背後に制限していると思うし、運用に影響が出ないタイミングでアップグレードする予定なんじゃないかな。公開インスタンスはすぐにアップデートすべきだけど、記事に書いてある内容から脆弱性を再現する方法を考えるのはそんなに難しくないし、GitHub Enterpriseのソースが公開されているのも影響してるよね。
└
GHESは実質的にメンテナンスされてない（「命のサポート状態」と言った方が優しいかも、だって確実にお金は取ってるし）で、もう10年くらいそんな感じ。パッチレベルのリリースを適用するのに数時間のダウンタイムが必要なんだ。HAアップグレードのためのサポートされたメカニズムもないから、最も真面目なGHESの顧客ですら最新バージョンに追いつけない。自社ホスティングの製品に重大な欠陥があると文句を言うGHESの顧客には、GitHub Enterprise Cloudに移行するように言ってるけど、今の時代にそれをする人がいると思う？少なくともGHESは、日々のgithub.comのダウンタイム中も動いてるからね。
AIがソースコードの脆弱性を見つけるのには感心したけど、バイナリエグゼキュータブルでそれをやるのは本当にすごい。これには良い面も悪い面もたくさんの可能性があるね。データを指示として扱わないっていうもう一つの教訓だ。ユーザー入力は全部サニタイズしないと！
└
トランスフォーマーは文字通り翻訳のために設計されました。しばらく前から分かっていたように、ソースからソース、またはテキストからソースへの翻訳が得意です。アセンブリ版を理解するのも得意なのはあまり驚くべきことではないでしょう。印象が薄れるわけではないけど、驚きは少ないかも。
ここにWizで働いてる人いる？結構いい仕事してるみたいだね。ツール自体は極端な成長や機能の肥大化を乗り越えて、まだうまくやってる。セキュリティチームは本当に面白いものを見つけてるよ。
わお、これが実際に悪用されたかどうか分かるのかな？
└
僕の理解では、この脆弱性は匿名のユーザーによって悪用可能だと思う。絶対にHTTP/gitプロトコルのログがあって、これが悪用されたかどうかは分かるはずだけど、もしそうだったとしても、実際に何がアクセスされたのか、誰がやったのかのログは残ってないだろうね。なぜなら、悪用はgitサーバー上でスタンドアロンで実行できたから、定義上、ログを回避できたはずだから。
これは本当に素人っぽい脆弱性だね。中身を考えずに文字列をくっつけて、後で解析するなんて… 編集：これは記事や脆弱性の見つけ方を貶めるつもりじゃなかったけど、どっちにしても建設的なコメントではなかったね。
└
脆弱性が実際に何だったのかについての情報を追加するのはいいけど、貶めるような形ではやめてほしいな。もっと別のアプローチを目指してるんだから。 https://news.ycombinator.com/newsguidelines.html
彼らは、現在のLLMエージェントのコアな強みの一つを示すAI強化リバースメソッドについてほのめかしています。このモデルは、コードに関して広範にトレーニングされていて、複雑なシステム内部を理解するプロセスを大幅に加速させることができます。セキュリティリサーチには、歴史的に二つの難しい要素があり、これらは相互に関連しています。1. 複雑なシステム内部の理解：抽象やインターフェースによって隠された内部の仕組みを明らかにすること 2. これらの明らかにされたメカニズムの中に脆弱性を見つけること 時には、両方のステップが同じくらい難しいこともあります。しかし、実際のメカニズムが明らかになると、脆弱性を見つけるのは簡単になることが多いです。内部の仕組みについての仮定に頼るのではなく。CVE-2026-3854は、内部を理解した後でも脆弱性が明らかではないケースです。それでも、もしもっと伝統的な攻撃面にさらされていたら、このコマンドインジェクションはすぐに見つかっていたと思います。
Wizからのまた別の力作で、AIツールがREや侵害発見を可能にする転換点です。
└
ソースを公開しない理由として、AIがコードを簡単に侵害するという主張に対して、逆に反論を投げかけます。セキュリティを隠蔽で行うことに対するもう一つのデータポイントですね。