2026年3月4日、GitHubのバグバウンティプログラムを通じて、GitHub Enterprise ServerおよびGitHub.com全体に影響を及ぼす重大なリモートコード実行（RCE）脆弱性、CVE-2026-3854が報告されました。報告を受けたGitHubは、2時間以内にGitHub.com向けの修正を展開し、その後、Enterprise Serverの全サポート対象バージョンに対するパッチをリリースしました。CVSS v3.1基準で8.7（High）と評価された本脆弱性は、git pushパイプライン内部のメタデータヘッダー処理過程で発生するコマンドインジェクションの問題です。リポジトリへのpush権限を持つ認証済みユーザーであれば、たとえ自分で作成した空のリポジトリ1つだけであっても、サーバー上で任意のコードを実行できる構造的な欠陥です。
特にGitHub Enterprise Server環境では、サーバー全体の掌握や、すべてのリポジトリおよび内部設定情報へのアクセスが可能になります。また、GitHub.comの共有マルチテナントインフラでは、同一ストレージノード上にホスティングされた他組織・他ユーザーの数百万件規模のリポジトリがクロス露出する結果につながる可能性がありました。公開時点では、GitHub Enterprise Serverインスタンスの88％が依然として脆弱なバージョンで運用されていることが確認されています。
本記事では、CVE-2026-3854の技術的構造と侵害フローを分析し、外部に公開されたGitHub Enterprise Server資産がどのような攻撃対象領域を形成するのかを考察します。
CVE-2026-3854 RCE脆弱性の概要
| 項目 | 内容 |
|---|---|
| 脆弱性ID | CVE-2026-3854 |
| 影響製品 | GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Server |
| 脆弱性タイプ | Command Injection |
| CVSSスコア | 8.7 (High) |
| 影響バージョン | GitHub Enterprise Server 3.14.24未満、3.15.19未満、3.16.15未満、3.17.12未満、3.18.6未満、3.19.3未満 |
| 修正バージョン | 3.14.24以降、3.15.19以降、3.16.15以降、3.17.12以降、3.18.6以降、3.19.3以降 |
本脆弱性は、git pushの過程で渡されるユーザー入力が、内部サービス間のメタデータとして伝達される際に適切に検証されないことで発生します。
技術的原因：内部サービス信頼モデルの綻び
CVE-2026-3854の本質は、git pushパイプラインを構成する複数の内部サービス間に存在する信頼モデルにあります。各コンポーネントは個別には正しく動作していましたが、相互にデータを受け渡す過程において、入力値の検証が欠落していました。
git pushパイプラインの構造
ユーザーがgit pushコマンドをSSH経由で送信すると、リクエストはbabeld（git SSHプロキシおよびエントリポイント）→ gitauth（内部認証サービス）→ gitrpcd（内部RPCサーバー）→ pre-receive hook（セキュリティポリシーの適用）という順序で処理されます。この過程でbabeldは、push処理に関するセキュリティ関連の設定値をX-Statという内部ヘッダーに構成し、下位サービスへ渡します。X-Statヘッダーは、セミコロン（;）を区切り文字とするキー・バリュー形式(key=value;key=value;...)で構成されています。
脆弱性の発生箇所
問題となったのは、babeldがユーザーの入力したgit pushオプション（-o 또는 --push-option）の値を適切に検証しないまま、X-Statヘッダーにそのまま挿入していた点です。X-Statのフィールド区切り文字であるセミコロンが、ユーザー入力内でもそのまま使用可能な状態となっており、さらにヘッダーパーサーは最後に出現した値を優先して適用する（last-write-wins）方式で動作していました。攻撃者は、pushオプションの値にセミコロンと細工されたキー・バリューの組み合わせを含めるだけで、X-Statヘッダー内の正規フィールドを上書きすることができました。下位サービスは、X-Statヘッダー内のすべてのフィールドを信頼できる内部データとして処理していたため、注入された値も正当な内部設定値として解釈されてしまいました。
3段階の注入チェイニング：サンドボックス回避から完全掌握まで
CVE-2026-3854を分析した研究チームは、3つの注入を連続的にチェイニングすることで、完全なRCEに到達できる経路を実証しました。
第1段階では、rails_env 注入によってサンドボックスを回避します。rails_env=nonprod という値をX-Statに注入すると、サーバーは本番環境のセキュリティ制約が適用されない非本番モードへ切り替わります。この環境では、pre-receive hook実行時に通常は無効化されているコードパスが有効になります。
第2段階では、 custom_hooks_dir注入によってフック実行ディレクトリを操作します。攻撃者が制御するディレクトリをフックの実行パスとして設定できるようになり、この段階でサーバーファイルシステムに対するパストラバーサルが可能になります。
第3段階では、 repo_pre_receive_hooks 注入によって任意コマンドを実行します。細工されたフック項目を挿入し、これをパストラバーサルと組み合わせることで、最終的にgitサービスユーザー権限でサーバー上の任意ファイルを実行できるようになります。研究チームはこの段階で、ファイルシステムに対する読み書き権限と、内部サービス設定に対する完全なアクセス権を取得できることを確認しました。
GitHub.comにおける追加の攻撃経路
GitHub.comでは、デフォルトでカスタムフックが無効化されているため、前述のチェイニングは直接適用されません。しかし、Enterprise Serverモードを有効化するenterprise_mode フラグもX-Statヘッダーを通じて渡されるため、同じ注入メカニズムによってこのフラグをtrueに設定することが可能でした。これにより、GitHub.com上でもカスタムフックの実行経路が有効化され、同一のRCEチェイニングが成立する状態となります。さらに、GitHubの共有マルチテナントアーキテクチャという特性上、攻撃に成功したストレージノードにホスティングされていた他組織・他ユーザーの公開および非公開リポジトリ数百万件にアクセス可能となる危険性がありました。
Criminal IPで観測された外部公開GitHub Enterprise Server資産
インターネット上に公開されたGitHub Enterprise Serverインスタンスの状況を把握するため、Criminal IP IT資産検索を活用し、外部公開資産を観測しました。
Criminal IP 検索クエリ: title: GitHub Enterprise
GitHub Enterprise ServerのWebインターフェースは、ログインページのタイトルに「GitHub Enterprise」を含む特徴があります。そのため、Criminal IP IT資産検索のタイトルベース検索を使用することで、管理UIが外部に公開されているインスタンスを直接識別できます。CVE-2026-3854は、push権限を持つユーザーであれば誰でも攻撃可能であるという特性を持ちます。そのため、管理インターフェースだけでなく、Git SSH／HTTPアクセスが可能なすべての外部公開インスタンスが攻撃対象領域となります。現在、GitHubはパッチを配布しており、多くの資産ではすでにパッチが適用されています。一方で、Criminal IPを通じて確認すると、まだパッチバージョンが適用されていない可能性があり、外部から公開アクセス可能なインスタンスを識別できます。検知結果では、2026年5月初旬時点で約2,204件の資産が識別されました。これらの資産は前述のとおり、push権限を持つユーザーであれば誰でも攻撃対象となり得るため、迅速な確認と対応が求められます。
Criminal IP IT資産検索を通じて、今回のCVE-2026-3854に対して脆弱な特定資産を分析しました。その結果、当該資産は高いリスクを持つものとして分類されており、22番ポート（SSH）と80番ポート（HTTP）が外部に開放されていることが確認されました。また、追加の脆弱性8件とポリシー違反1件もあわせて識別されました。これは単なる資産の露出にとどまらず、開発インフラまたは関連する運用環境が、インターネット上から攻撃者によって直接アクセス可能な状態にある可能性を示しています。
GitHub Enterprise Serverは、組織のソースコード、内部文書、CI/CD構成、デプロイスクリプト、シークレット情報が集中する中核的な開発インフラです。このような特定資産が外部に公開された状態で維持されている場合、攻撃者はリポジトリへのpush権限だけでサーバー内部の実行環境を操作し、ファイルシステムへのアクセス、内部設定情報の窃取、リポジトリおよびパイプラインの改ざんへと攻撃を拡大できる可能性があります。したがって、このような特定資産は、組織の開発およびデプロイ体制全体につながり得る高リスクの攻撃対象領域として、優先的に点検する必要があります。
パッチ状況および対応方法
CVE-2026-3854は、GitHub内部プロトコルの処理過程における入力検証の不備により発生した脆弱性です。GitHubは本問題を認識した直後、入力値に対するフィルタリングおよびメタデータ処理ロジックを改善し、パッチを適用しました。
GitHub Enterprise Serverでは、以下のバージョンで修正が反映されています。
- 3.14.24 以降
- 3.15.19 以降
- 3.16.15 以降
- 3.17.12 以降
- 3.18.6 以降
- 3.19.3 以降
また、クラウド環境（GitHub.comおよびEnterprise Cloud）では、即時のサーバー側パッチにより脆弱性が解消されたことが確認されています。
しかし、本脆弱性は単なるコード上の欠陥ではなく、「ユーザー入力が内部の信頼データとして処理される構造そのもの」から発生した問題である点に注意が必要です。特にGitHub Enterprise Serverのように組織内部で運用される環境では、パッチ適用前にすでに攻撃が行われていた可能性を考慮する必要があります。攻撃者は、単純なgit pushリクエストだけで内部実行環境を改ざんできる可能性があります。さらに、hook実行環境の変更を通じた任意コード実行、ファイルシステムへのアクセスおよび内部設定情報の窃取、リポジトリやCI/CDパイプラインの改ざん、サーバー構成および認証情報の露出といった行為につながる可能性があります。これは、開発インフラ全体に対する権限奪取へ発展し得るものです。
したがって、組織は単にパッチを適用するだけでなく、すでに侵害が発生している可能性を念頭に置いて対応する必要があります。具体的には、以下の対応が求められます。
- GitHub Enterprise Serverを最新バージョンへ即時アップデート
- 外部からアクセス可能なインスタンスに対するVPNまたはIPベースのアクセス制限の適用
- リポジトリのpush権限の最小化および不要な権限の削除
- hook実行環境およびcustom hook設定の点検
- 異常なpushイベントおよび実行ログのモニタリング
結果として、今回の事案における本質的な対応は、パッチ適用にとどまらず、外部に公開された開発インフラの統制と、侵害を前提とした包括的な対応にあります。外部に公開されたGitHub Enterprise Serverインスタンスを識別し、アクセスを制限することは、単一の脆弱性対応を超えて、組織全体の開発環境を保護するための重要な要素となります。
FAQ
Q1. 認証が必要な脆弱性であるにもかかわらず、なぜCritical相当として扱う必要があるのですか？
push権限の取得ハードルは非常に低いためです。攻撃者はGitHub上で直接アカウントを作成し、空のリポジトリを1つ作成するだけで攻撃条件を満たすことができます。GitHub.comでは、クロステナント露出により、同一ストレージノード上の他組織の非公開リポジトリまでアクセス可能となる恐れがあります。また、GitHub Enterprise Serverでは、サーバー全体の掌握につながる可能性があります。
Q2. GitHub.comはすでにパッチ適用済みであるにもかかわらず、なぜGitHub Enterprise Serverは依然として危険なのですか？
GitHub.comはクラウドサービスであるため、GitHubが直接、即時にパッチを適用できます。一方、GitHub Enterprise Serverは、各組織が自社インフラ上で運用するセルフホスティング型ソリューションであるため、運用組織自身がアップグレードを実施する必要があります。2026年5月初旬時点では、88％のインスタンスが未パッチ状態であったことが確認されています。さらに、技術情報やPoCがすでに知られている状況では、パッチ適用の遅れが即時の攻撃リスクにつながります。そのため、パッチ適用は必須であり、実際の運用組織では監査ログの確認および侵害有無の調査まで実施する必要があります。さらに、必要に応じてリポジトリへのアクセス履歴を確認し、内部シークレット全体をローテーションする対応も求められます。
結論
CVE-2026-3854は、世界最大級のコードホスティングプラットフォームの中核インフラにおいて、git pushパイプライン内のたった1つのセミコロンが、数百万件のリポジトリを脅かし得ることを示した事例です。今回の事案が特に注目される理由は、脆弱性そのものの破壊力だけではありません。報告から2時間という迅速な対応、さらにフォレンジック調査を通じて悪用の痕跡が確認されなかったことまで含め、責任ある公開対応プロセスが実施された点にもあります。しかし、このような迅速な対応にもかかわらず、セルフホスティング型のGitHub Enterprise Serverを運用する組織において、パッチ適用率が依然として低いという事実は、別の課題を示しています。脆弱性が修正されたとしても、外部に公開された未パッチのインスタンスが残っている限り、攻撃者の視点では有効な攻撃対象領域が存在し続けます。組織が運用するGitHub Enterprise Serverインスタンスがどこに存在し、どのバージョンを使用しているのかを把握すること、そしてそのインスタンスがインターネット上にどの程度公開されているのかを継続的にモニタリングすることは、パッチ適用と同じくらい重要です。
なお、関連して CVE-2021-39935：GitLab CI Lint API におけるサーバーサイドリクエストフォージェリ脆弱性 の記事も参考にしてください。
Criminal IP（search.criminalip.io/ja/register) に登録すると、すぐに脆弱資産の検知を開始できます。さらに、下記ボタンからデモをご依頼いただくことで、エンタープライズ環境において外部に露出した資産を対象としたCriminal IP の脅威インテリジェンス（TI）分析を直接ご確認いただけます。
本レポートは、サイバー脅威インテリジェンス検索エンジン Criminal IP のデータを基に作成されています。
今すぐCriminal IP の無料アカウントを作成すれば、本レポートで引用された検索結果を直接確認したり、さらに膨大な脅威インテリジェンスを自由に検索することができます。
データソース : Criminal IP (https://www.criminalip.io/ja), BleepingComputer(https://www.bleepingcomputer.com/news/security/cisa-warns-of-five-year-old-gitlab-flaw-exploited-in-attacks/), CyberSecurityNews (https://cybersecuritynews.com/cisa-warns-gitlab-ssrf-vulnerability-exploit/)