GitLab の Webhook で未認証SSRF（内部ネットワークへ到達・悪用確認済み）

Critical（CVSS 9.8）に分類されるGitLab GitLab CE/EEの脆弱性です。GitLab に SSRF があり、Webhook から内部ネットワークへのリクエストが許可されている設定のとき、登録を無効化しているインスタンスであっても未認証の攻撃者から悪用できた。NVD の説明はこの条件と、10.5 以降のすべての版が影響するという点を挙げている。SSRF は GitLab のサーバを踏み台にして内部だけに公開されているサービスへ HTTP リクエストを送らせるもので、クラウド上では特にインスタンスメタデータサービスや内部の管理エンドポイントへの到達が問題になる。影響範囲は CPE で 10.5.0 以上 13.6.7 未満、13.7.0 以上 13.7.7 未満、13.8.0 以上 13.8.4 未満とされ、CE と EE の両方が対象。したがって修正が入ったのは 13.6.7、13.7.7、13.8.4 である。CVSS は評価元で大きく割れている。NVD（Primary）は 9.8 Critical（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）、CNA の GitLab は 6.8 Medium（CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N）で、GitLab 側は攻撃条件が難しく影響は情報漏えいに限られるという見方、NVD 側は完全性と可用性まで含めた最大影響で評価している。旧 CVSS v2 では 6.8。公開は 2021年6月11日だが、CISA KEV への収載は 2026-02-18 で是正期限は 2026-03-11、ランサムウェア利用は Unknown。NVD の vulnStatus は Analyzed で、4年以上前の脆弱性が現役の攻撃対象として再浮上した例である。

現行の GitLab を普通に運用していれば修正済みの版が入っているのが通常で、この CVE は古いインスタンスの残存確認になる。自己管理型（Self-Managed）の GitLab の版は管理エリアの画面か /help、または gitlab-rake gitlab:env:info で確認でき、13.6.7 / 13.7.7 / 13.8.4 のいずれの修正版にも達していない 10.5 以降の版なら該当する。GitLab.com のような SaaS 側は運営が更新するため利用者側の作業はない。見落としやすいのは、移行後に読み取り専用として残した旧インスタンス、オンプレの部門サーバ、そして omnibus パッケージを長期間更新していない環境である。すぐに更新できない場合の緩和策は説明文の条件をそのまま裏返すのが基本で、管理エリアのネットワーク設定にある Webhook とサービスから内部ネットワークへのリクエストを許可する設定を無効化し、許可リストも必要最小限にする。加えてクラウド上ではメタデータサービスへの到達を潰しておくことが効く。AWS なら IMDSv2 を必須にし、egress のファイアウォールで内部セグメントと 169.254.0.0/16 宛を拒否する。完了条件は、（1）自己管理インスタンスが 13.6.7 / 13.7.7 / 13.8.4 以降（実運用では現行のサポート版）になっていること、（2）Webhook の内部ネットワーク許可設定が意図した状態であること、の2点である。KEV 収載済みで実際に悪用されているため、古い版を長く外部公開していた場合は更新だけで終わらせない。SSRF はまず内部の探索と資格情報の取得に使われるので、GitLab ホストから内部宛の不審なアクセスログ、インスタンスに紐づくロールの利用履歴を確認し、CI/CD 変数やデプロイトークン、SSH 鍵は再発行する。是正期限 2026-03-11 は既に過ぎているため、残存インスタンスは期限超過として最優先で処理する。

GitLab GitLab CE/EE を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2021-22175）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。

はい。CISA の既知の悪用された脆弱性カタログ（KEV）に登録されており、実環境での悪用が確認されています。米国連邦機関向けの対応期限の目安は 2026/03/11 です。推奨される対応: ベンダーの指示に従って緩和策を適用し、クラウドサービスについては該当する BOD 22-01 のガイダンスに従うこと。緩和策が無い場合は当該製品の使用を停止すること。