GitHubがGHES 3.20.3をリリース-事前認証SSRFが可能な脆弱性を修正-CVE-2026-9312|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月29日更新日時: 2026年05月29日

GitHubは2026年5月26日、GitHub Enterprise Server（GHES）バージョン3.20.3をリリースしました（GitHub Enterprise Server 3.20公式リリースノート）。本リリースはGHES 3.16〜3.21の全サポートバージョンを対象とした横断的なセキュリティパッチリリースであり、アップロードエンドポイントの事前認証SSRF（CVE-2026-9312・Critical）を筆頭に複数の深刻な脆弱性を修正しています。

同日、GitHubはセキュリティブログで「GitHubがサイバー攻撃を検知し、即座にインシデント対応を開始した」と発表（GitHub Security Blog・2026年5月26日）。攻撃を受けたリポジトリへの配慮と予防的措置としてGHESリリースパッケージの署名鍵をローテーションするとしており、GHES管理者はアップデートを適用する前にGPG公開鍵のローテーション作業が必須となっています。

当サイトでは既報記事でGitHub内部リポジトリへの不正アクセス問題を詳報しており、今回の署名鍵ローテーションはその継続対応として位置づけられます。

1 この記事のサマリー
2 なぜ「署名鍵のローテーション」が必要なのか
3 CVE-2026-9312—最も深刻な「事前認証SSRF」の技術詳細
- 3.1 攻撃の仕組み
- 3.2 なぜ「事前認証」が深刻なのか
4 CVE-2026-43284・CVE-2026-43500-「Dirty Frag」Linux権限昇格
5 CVE-2026-8606-タイミングサイドチャネル+環境変数漏洩
6 アップデート前の必須作業——署名鍵ローテーション手順
7 全サポートバージョンへの適用状況
8 GitHubのサイバー攻撃インシデントとの関連性
9 FAQ
10 参考情報（1次ソース）

この記事のサマリー

今回のGHES 3.20.3で修正された主要な脆弱性

CVE	深刻度	種別	攻撃条件	概要
CVE-2026-9312	Critical	事前認証SSRF	ネットワーク経由（認証不要）	アップロードエンドポイントの不十分な入力検証→内部サービスへのHTTPリクエスト送信・認証情報漏洩
CVE-2026-43284	High	Linux権限昇格「Dirty Frag」	ローカルアクセス（シェルアクセス）	Linux カーネルIPsec ESPサブシステムの脆弱性→rootへの権限昇格
CVE-2026-43500	High	Linux権限昇格「Dirty Frag」	ローカルアクセス（シェルアクセス）	LinuxカーネルRxRPCネットワークサブシステムの脆弱性→rootへの権限昇格
CVE-2026-8606	High	タイミングサイドチャネル+SSRF	ネットワーク経由（プライベートモード無効時は未認証）	ノートブックビューアのタイミング側チャネル→環境変数の抽出・GitHub Packagesを通じたSSRF
CVE-2026-5921	Medium	内部パッケージエンドポイントSSRF	ネットワーク経由（プライベートモード無効時は未認証）	内部パッケージエンドポイントが未認証のSSRFとして悪用可能

対象バージョン：GHES 3.16〜3.21の全サポートバージョン
3.20系の修正済みバージョン：3.20.3（※後続の3.20.4でも同CVEに追加対応）
⚠️ 最重要：アップデート前にGitHub提供のスクリプトを使用したGPG署名鍵のローテーションが必須
背景：GitHubがサイバー攻撃を検知したことによる予防的署名鍵ローテーション

なぜ「署名鍵のローテーション」が必要なのか

今回のGHES 3.20.3の最も重要な管理上の変更は、単なる脆弱性のパッチ適用ではなくGPG署名鍵のローテーションを伴う点です。

GitHubのセキュリティブログ（2026年5月26日）は次のように説明しています。「GitHubは最近サイバー攻撃を検知し、直ちに調査・悪意ある活動の中断・攻撃の緩和・脅威アクターのアクセス遮断を行うインシデント対応を開始した。この調査は現在も進行中であり、適切な範囲で詳細を継続的に提供する。攻撃を受けたリポジトリと予防的措置を考慮し、GHESの署名鍵を含む鍵をローテーションしている。この鍵はGHESリリースパッケージに署名し、手動で開始されるアップデートプロセスの際にGitHubをソースとして検証するために使用される。」

GHESの署名鍵は、GHES管理者が更新パッケージを適用する際に「そのパッケージが正規のGitHubから提供されたものである」ことを検証するために使用されます。鍵がローテーションされるということは、古い鍵を使用したままではアップデートを適用できず、事前に新しい公開鍵をインスタンスに登録する作業が必要になります。

CVE-2026-9312—最も深刻な「事前認証SSRF」の技術詳細

攻撃の仕組み

GitHub公式リリースノートによれば、攻撃者はアップロードエンドポイントへのリクエストパラメーターにパストラバーサルコンテンツを注入することで、意図したリクエストフローをバイパスし内部APIコールをリダイレクトすることができました。

CyberSecurityNewsの報道によれば、GHESインスタンスへのネットワークアクセスを持つ攻撃者（認証不要）が細工されたリクエストを送信することで、GHESサーバーが内部サービスへのHTTPコールを発行します。これにより攻撃者は内部サービスへの不正アクセスや機密情報・設定データの漏洩を引き起こせる可能性がありました。本脆弱性はGitHubのバグバウンティプログラムを通じて外部研究者から報告されました。

なぜ「事前認証」が深刻なのか

サーバーサイドリクエストフォージェリ（SSRF）の多くは認証済みユーザーが必要ですが、CVE-2026-9312は一切の認証なしに攻撃できます。GHESインスタンスがインターネットや信頼されていないネットワークからアクセス可能な場合、攻撃者はGitHubアカウントさえ持たずに攻撃を実行できます。内部ネットワークに設置されたGHESインスタンスであっても、クラウド環境のIMDSサービスや内部のCI/CDシステムへのSSRF経由アクセスが懸念されます。

CVE-2026-43284・CVE-2026-43500-「Dirty Frag」Linux権限昇格

CyberSecurityNewsの分析によれば、これら2件はLinuxカーネルの以下のネットワークサブシステムに存在する権限昇格脆弱性です。

CVE-2026-43284はIPsec ESPネットワークサブシステムの脆弱性で、CVE-2026-43500はRxRPC（Remote Procedure Call over UDP）ネットワークサブシステムの脆弱性です。

両者ともにGHESアプライアンスへのシェルアクセスを持つローカルの攻撃者が一般ユーザーアカウントからroot権限に昇格することを可能にします。GitHubは「共有環境において複数のチームや自動化プロセスがシェルアクセスを持つ場合、アプライアンスへの低権限の足がかりが完全な侵害へとエスカレートするリスクを低減する」とその重要性を説明しており、GHESのバンドルされたLinuxカーネルを修正版に更新することで対処しています。

CVE-2026-8606-タイミングサイドチャネル+環境変数漏洩

GBHackersの報道によれば、本脆弱性はGitHub Packagesのノートブックビューア（notebook viewer）に存在するタイミングサイドチャネル攻撃と、その悪用によってGHESインスタンスの環境変数が外部に漏洩するという2段階の問題です。

特に深刻なのは、プライベートモードが無効（private mode disabled）の場合には認証なしにこの攻撃が可能という点です。GitHubの多くのエンタープライズ導入ではプライベートモードが有効に設定されていますが、デフォルト設定やテスト環境では無効のまま運用されているケースもあります。環境変数の漏洩は、APIキー・データベースパスワード・内部サービスのシークレットなどの機密情報を攻撃者に提供するため、横展開攻撃の入口となります。

アップデート前の必須作業——署名鍵ローテーション手順

GitHubが提供するスクリプトを使用して、アップデート前に必ず署名鍵のローテーションを実施してください。

# Step 1: GitHubが提供する鍵ローテーションスクリプトをダウンロードして実行
# 詳細な手順はGitHub公式ドキュメントを参照
# https://docs.github.com/en/enterprise-server/admin/release-notes

# Step 2: GPG公開鍵のローテーション確認
ghe-config app.github.package-signing-key-rotated

# Step 3: GHESアップデートの実施（鍵ローテーション完了後）
ghe-upgrade ghes-3.20.3.pkg

# または管理コンソール（https://<hostname>:8443）からGUIでアップデート

全サポートバージョンへの適用状況

今回のセキュリティパッチはGHESの全サポートバージョンに横断的に適用されています。OffSeq.comの情報によれば最終的な修正バージョンは以下の通りです。

GHES系列	CVE-2026-9312修正バージョン
3.16系	3.16.20
3.17系	3.17.17
3.18系	3.18.11
3.19系	3.19.8
3.20系	3.20.3（本記事対象）→ 3.20.4
3.21系	3.21.1

各系列の最新セキュリティバージョンへのアップデートを推奨します。

GitHubのサイバー攻撃インシデントとの関連性

今回の署名鍵ローテーションはGitHubが検知したサイバー攻撃への対応の一環です。当サイトでは以前、GitHub社内リポジトリへの不正アクセスを巡る一連の報道を詳報しており、TanStack・Nxを経由したサプライチェーン攻撃連鎖の文脈でこれらの動きが理解できます。GitHubは「All binaries hosted by GitHub are valid（GitHubがホストするすべてのバイナリは有効である）」と述べており、署名鍵ローテーションは予防的措置であることを強調しています。

今後もGitHubは「今後数か月にわたり、より高い頻度でGHESセキュリティアップデートを適用する準備をするよう顧客に推奨する」としており、GHESを使用する組織は通常よりも短いサイクルでのアップデート対応が求められます。

FAQ

Q. GitHub.com（クラウド版）を使っているユーザーも対応が必要ですか？ A. 今回の修正はセルフホスト版のGitHub Enterprise Serverに対するものです。GitHub.comやGitHub Enterprise Cloudは既にGitHub側で修正済みであり、ユーザー側の対応は不要です。

Q. 署名鍵のローテーション作業はどの程度の時間がかかりますか？ A. GitHubが提供するスクリプトを使用した場合、通常は数分程度で完了します。ただし環境によって異なる場合があるため、メンテナンスウィンドウを確保した上で実施することを推奨します。

Q. 署名鍵ローテーションを行わずにアップデートを試みるとどうなりますか？ A. 旧来の鍵が失効しているため、アップデートの署名検証が失敗してアップデートを適用できません。必ずGitHub公式ドキュメントの手順に従って鍵のローテーションを先に実施してください。

Q. CVE-2026-9312はGHESが社内ネットワークのみに設置されていても危険ですか？ A. 社内ネットワーク内部にいる攻撃者（侵害されたホスト・内部の不正行為者）からも悪用可能です。また社内ネットワークからクラウドIMDSサービスへのSSRFも懸念されます。認証不要という特性から、ネットワーク経由で到達できるすべての環境でリスクがあります。