脆弱性対応ウォッチ重大・クリティカル脆弱性のクラウド別対応まとめ
最新更新履歴CriticalHigh回避策のみパッチありAWSGCPAzureLinux
Critical CVSS 9.1
CVE-2026-17556

GitHub Enterprise Server の未認証パストラバーサルで任意のファイル・ディレクトリを削除される

情報取得日: 2026/08/05/最終確認: 2026/08/30・本ページは公開情報の非公式まとめです

CVE IDCVE-2026-17556
製品GitHub / GitHub Enterprise Server。3.22 より前の全バージョンが該当し、3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 で修正された。
CVSS9.1(Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
種別 (CWE)CWE-22 制限されたディレクトリへのパス名の不適切な制限(パストラバーサル)
登録/公開日2026/08/05
出典https://nvd.nist.gov/vuln/detail/CVE-2026-17556

概要

自社で運用する GitHub、GitHub Enterprise Server(GHES)に、認証を持たない攻撃者がインスタンス上の任意のファイルとディレクトリを削除できる欠陥がある。削除対象には、Git LFS のオブジェクト、リリースの成果物、添付ファイル、アバターを収めた利用者ストレージのディレクトリ全体が含まれる。 成立の筋道は NVD の記述が具体的に書いている。GHES はアップロード用のバッファディレクトリを決めるとき、X-GitHub-Request-Id というリクエストヘッダの値を、サニタイズせずにファイルシステムのパスの一部として使っていた。そのためヘッダにパストラバーサルの値(上位ディレクトリへ遡る表記)を入れると、バッファの位置を任意のパスへ向けられる。GHES はアップロード後にこのバッファを遅延して片付ける処理を持っており、その片付けが再帰的に対象を削除する。つまり「置き場所を差し替えてから、片付けさせる」という形で、攻撃者が指したディレクトリが丸ごと消える。 **成立条件が非常に緩い。**必要なのはインスタンスへネットワーク到達できることだけで、認証は要らない。さらに、外部からの匿名アクセスを塞ぐ private mode を有効にしていても成立したと明記されている。**「社外に見せていないから大丈夫」という前提が効かない**種類の欠陥である。 CVSS は NVD の主評価で 3.1 の 9.1(Critical)、ベクタは AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H である。機密性への影響は None で、完全性と可用性が High に振れている。読み取られるのではなく、壊されるということである。データが外へ出ないぶん気づきにくく、被害は消えたものとして現れる。 影響範囲は 3.22 より前の全バージョンで、修正版は 3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 の5系列に出ている。GitHub の Bug Bounty プログラム経由で報告されたもので、2026-08-29 時点で CISA KEV には収載されていない(悪用の確認は公表されていない)。ただし認証不要かつ攻撃条件が Low なので、KEV に載っていないことを安全の根拠にはできない。

クラウド/OS 別の対応状況

各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。

AWS / GCP / Azure は同じ対応区分です: パッチあり(アプリ更新)
Linux のみ異なります: ベンダーFW更新
環境対応状況対応方法・備考
AWS (ECS/EC2) パッチあり(アプリ更新)
EC2 上で運用している GHES を、自系列の修正版(3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19)または 3.22 以降へ更新する。AWS 側の修正は無い。
AWS はマネージドの GHES を提供していないため、AWS 個別のアドバイザリは存在しない(2026-08-29 時点で確認できていない)。ALB や WAF を前段に置いている場合、X-GitHub-Request-Id ヘッダにパス区切りを含むリクエストを落とすことは緩和にあたるが、正式な回避策ではない。EBS スナップショットからの復旧可否を、更新前に確認しておくこと。
参照リンク
GCP パッチあり(アプリ更新)
Compute Engine 上の GHES を、自系列の修正版または 3.22 以降へ更新する。GCP 側の対応は不要。
GCP からの本 CVE 個別のセキュリティ速報は確認できていない(2026-08-29 時点)。Cloud Armor でヘッダを見て遮断することは緩和にあたる。永続ディスクのスナップショットからの復旧可否を確認しておくこと。
参照リンク
Azure パッチあり(アプリ更新)
Azure VM 上の GHES を、自系列の修正版または 3.22 以降へ更新する。Azure 側の対応は不要。
Azure からの本 CVE 個別のセキュリティ速報は確認できていない(2026-08-29 時点)。Application Gateway WAF でのヘッダ検査は緩和にあたる。
参照リンク
Linux ベンダーFW更新
GHES は仮想アプライアンスとして提供されるため、ディストリのパッケージ更新では対処できない。GHES 本体を管理コンソールから修正版へ更新する。
Ubuntu USN / Red Hat RHSA / Debian security tracker のいずれにも本 CVE の項目は無い(2026-08-29 時点)。GHES の内部は Linux だが、更新の単位はアプライアンスのイメージであり、OS のパッケージ管理の外にある。この点で、ホスト側のパッチ運用に乗せていると更新漏れが起きやすい。
参照リンク

解決の方向性(パッチ/回避策/代替)

対応は GHES を修正版へ更新することである。自分の系列に対応する 3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 のいずれか、または 3.22 以降へ上げる。**系列をまたぐ必要は無い**ので、いま 3.19 系なら 3.19.10 へ上げれば足りる。GHES の更新は互換性の確認が要る作業だが、この件は同一系列内のパッチ更新で塞げるため、大きな移行計画を待つ理由は無い。 **更新までのあいだの手当てとして、リクエストヘッダを見る手がある。**成立の入口は X-GitHub-Request-Id ヘッダの値なので、GHES の前段にリバースプロキシや WAF を置いているなら、このヘッダにパス区切りや上位ディレクトリへ遡る表記が含まれるリクエストを落とすことで到達を減らせる。ただしこれはベンダが正式な回避策として提示したものではないため、更新の代わりにはならない。 **到達範囲を絞る対策は、この件では効き方が限られる。**private mode を有効にしていても成立すると明記されているので、アプリケーション側の公開設定では塞げない。効くのはネットワーク層で到達そのものを断つことだけである。社内からのみ到達できる構成であっても、社内ネットワークに入られた時点で認証なしに成立するため、境界防御だけを根拠に優先度を下げるのは危うい。 **更新の前に、被害の有無を確認しておくこと。**この欠陥は読み取りではなく削除である。利用者ストレージのディレクトリ(Git LFS オブジェクト、リリース成果物、添付ファイル、アバター)が意図せず消えていないかを確認する。消えていた場合、Git のリポジトリ本体は残っていても LFS の実体だけが失われている、という形になりうる。バックアップからの復旧が可能かどうかを、更新作業とは別に確かめておく。

よくある質問(CVE-2026-17556)

CVE-2026-17556(GitHub Enterprise Server。3.22 より前の全バージョンが該当し、3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 で修正された。)の影響は?

Critical(CVSS 9.1)に分類されるGitHub GitHub Enterprise Server。3.22 より前の全バージョンが該当し、3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 で修正された。の脆弱性です。自社で運用する GitHub、GitHub Enterprise Server(GHES)に、認証を持たない攻撃者がインスタンス上の任意のファイルとディレクトリを削除できる欠陥がある。削除対象には、Git LFS のオブジェクト、リリースの成果物、添付ファイル、アバターを収めた利用者ストレージのディレクトリ全体が含まれる。 成立の筋道は NVD の記述が具体的に書いている。GHES はアップロード用のバッファディレクトリを決めるとき、X-GitHub-Request-Id というリクエストヘッダの値を、サニタイズせずにファイルシステムのパスの一部として使っていた。そのためヘッダにパストラバーサルの値(上位ディレクトリへ遡る表記)を入れると、バッファの位置を任意のパスへ向けられる。GHES はアップロード後にこのバッファを遅延して片付ける処理を持っており、その片付けが再帰的に対象を削除する。つまり「置き場所を差し替えてから、片付けさせる」という形で、攻撃者が指したディレクトリが丸ごと消える。 **成立条件が非常に緩い。**必要なのはインスタンスへネットワーク到達できることだけで、認証は要らない。さらに、外部からの匿名アクセスを塞ぐ private mode を有効にしていても成立したと明記されている。**「社外に見せていないから大丈夫」という前提が効かない**種類の欠陥である。 CVSS は NVD の主評価で 3.1 の 9.1(Critical)、ベクタは AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H である。機密性への影響は None で、完全性と可用性が High に振れている。読み取られるのではなく、壊されるということである。データが外へ出ないぶん気づきにくく、被害は消えたものとして現れる。 影響範囲は 3.22 より前の全バージョンで、修正版は 3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 の5系列に出ている。GitHub の Bug Bounty プログラム経由で報告されたもので、2026-08-29 時点で CISA KEV には収載されていない(悪用の確認は公表されていない)。ただし認証不要かつ攻撃条件が Low なので、KEV に載っていないことを安全の根拠にはできない。

CVE-2026-17556 の対応方法・回避策は?

対応は GHES を修正版へ更新することである。自分の系列に対応する 3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 のいずれか、または 3.22 以降へ上げる。**系列をまたぐ必要は無い**ので、いま 3.19 系なら 3.19.10 へ上げれば足りる。GHES の更新は互換性の確認が要る作業だが、この件は同一系列内のパッチ更新で塞げるため、大きな移行計画を待つ理由は無い。 **更新までのあいだの手当てとして、リクエストヘッダを見る手がある。**成立の入口は X-GitHub-Request-Id ヘッダの値なので、GHES の前段にリバースプロキシや WAF を置いているなら、このヘッダにパス区切りや上位ディレクトリへ遡る表記が含まれるリクエストを落とすことで到達を減らせる。ただしこれはベンダが正式な回避策として提示したものではないため、更新の代わりにはならない。 **到達範囲を絞る対策は、この件では効き方が限られる。**private mode を有効にしていても成立すると明記されているので、アプリケーション側の公開設定では塞げない。効くのはネットワーク層で到達そのものを断つことだけである。社内からのみ到達できる構成であっても、社内ネットワークに入られた時点で認証なしに成立するため、境界防御だけを根拠に優先度を下げるのは危うい。 **更新の前に、被害の有無を確認しておくこと。**この欠陥は読み取りではなく削除である。利用者ストレージのディレクトリ(Git LFS オブジェクト、リリース成果物、添付ファイル、アバター)が意図せず消えていないかを確認する。消えていた場合、Git のリポジトリ本体は残っていても LFS の実体だけが失われている、という形になりうる。バックアップからの復旧が可能かどうかを、更新作業とは別に確かめておく。

自分の環境が CVE-2026-17556 の影響を受けるか確認するには?

GitHub GitHub Enterprise Server。3.22 より前の全バージョンが該当し、3.21.4 / 3.20.6 / 3.19.10 / 3.18.13 / 3.17.19 で修正された。 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報(https://nvd.nist.gov/vuln/detail/CVE-2026-17556)で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド/OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

参考情報(出典)

本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください(最終確認: 2026/08/30)。

免責: 本ページは CISA KEV・NVD・各ベンダー公式アドバイザリ等の公開情報をもとにした非公式まとめです。修正バージョンや対応可否は変更される場合があります。実際の対応は必ず 出典元および各ベンダー公式情報・自環境で確認してください。

« 一覧に戻る