Spring Security の SAML 2.0 認証を使っているなら、まず影響を確認してください。SAML の SSO（シングルサインオン）ログイン／ログアウトで REDIRECT バインディングを利用する構成に、サービス拒否（DoS）につながる脆弱性 CVE-2026-40988 が見つかりました。認証前・遠隔・ユーザー操作不要で悪用でき、細工したリクエストを数回送るだけで JVM をメモリ枯渇（OutOfMemoryError）に追い込めます。対策はサポート対象ラインでは修正版へのアップデート、それ以外は回避策の適用です。
この記事でわかること
- CVE-2026-40988 は「何に」「どんな条件で」影響するのか
- 影響を受けるバージョンと修正版（OSSで直せる版と有償サポート限定の版の違い）
- 攻撃の仕組み（圧縮ペイロードの展開を悪用する「解凍爆弾」型）
- すぐに打てる回避策と、情シスとしての優先度の考え方
何が起きたのか
問題があるのは、Spring Security の SAML 2.0 サービスプロバイダー機能を提供するモジュール spring-security-saml2-service-provider です。SAML の REDIRECT バインディングでは、SAML メッセージを DEFLATE で圧縮し、URL に載せてやり取りします。受信側はこれを展開（解凍）してから処理しますが、この展開処理に上限（サイズ制限）が設けられていなかったため、攻撃者が「小さいけれど展開すると巨大になる」ペイロードを送り込むと、メモリを際限なく消費させられます。VMware（Spring）は 2026 年 6 月 9 日に公式アドバイザリを公開しました。
誰が影響を受けますか？
影響するのは、Spring Security で SAML 2.0 のログインまたはログアウトに REDIRECT バインディングを使っているアプリケーションです。IdP（Azure AD／Entra ID、Okta、Keycloak 等）と SAML で連携する社内 Web アプリを Spring で内製・カスタマイズしている組織が典型例です。SAML を使っていない、あるいは POST バインディングのみの構成であれば、この脆弱性の対象にはなりません。
どれくらい危険ですか？
評価は機関によって分かれます。NVD／JVN iPedia は CVSS 基本値 7.5（重要）（ネットワーク／攻撃条件の複雑さ低／権限不要／利用者関与なし、可用性への影響：高）としています。一方、Spring 公式アドバイザリは深刻度を MEDIUM（中）としています。いずれにせよ、情報漏えいや改ざんではなく可用性（サービス停止）に対する脅威で、認証基盤であるログイン処理を狙える点が実務上のポイントです。
影響を受けるバージョンと修正版
影響範囲と修正版は次のとおりです。注意したいのは、OSS（無償）で修正版が出るのは 6.5系と 7.0系のみで、それより古いラインの修正はエンタープライズ（有償）サポート契約者向けにのみ提供される点です。
| 影響を受けるバージョン | 修正版 | 入手方法 |
|---|---|---|
| 5.7.0 〜 5.7.23 | 5.7.24 | エンタープライズサポート限定 |
| 5.8.0 〜 5.8.25 | 5.8.26 | エンタープライズサポート限定 |
| 6.3.0 〜 6.3.16 | 6.3.17 | エンタープライズサポート限定 |
| 6.4.0 〜 6.4.16 | 6.4.17 | エンタープライズサポート限定 |
| 6.5.0 〜 6.5.10 | 6.5.11 | OSS（無償） |
| 7.0.0 〜 7.0.5 | 7.0.6 | OSS（無償） |
上記より古いサポート終了（EOL）バージョンも影響を受けますが、無償の修正は提供されません。EOL ラインを使い続けている場合は、これを機に 6.5系／7.0系への移行、または回避策の恒久適用を検討してください。
なぜ起きたのか（攻撃の仕組み）
根っこにあるのは、「圧縮データを無条件に展開してしまう」という典型的な落とし穴です。SAML の REDIRECT バインディングは通信量を抑えるため DEFLATE 圧縮を使いますが、展開後のサイズをチェックしていないと、攻撃者は圧縮率の高いデータ（例：同じ文字の繰り返し）を使って、小さな入力から巨大なメモリ確保を引き起こせます。これはいわゆる「解凍爆弾（decompression bomb／zip bomb）」と同じ発想です。認証前に到達できる入り口であるため、外部公開された SSO エンドポイントほどリスクが高くなります。
修正版では、展開処理を監視するガードを挟み、展開後サイズが 1 MiB（1,048,576 バイト）を超えた時点で Saml2Exception を投げて中断するようになりました。上限を設けることで、いくら圧縮されていても青天井のメモリ確保は起きなくなります。
情シスはどうすべきか
まず何をすべきですか？
最優先は自社に該当構成があるかの棚卸しです。「Spring 製の内製 Web アプリで SAML SSO を使っているか」「REDIRECT バインディングか」を確認し、該当すれば修正版へアップデートします。OSS で直せない古いラインの場合は、次の回避策を検討してください。
- SAML ログインの回避策：GET リクエスト経由の SAML レスポンス受け入れを無効化します。具体的には
OpenSaml5AuthenticationTokenConverter#setShouldConvertGetRequests(false)を設定します（REDIRECT バインディングでのレスポンス受信を止める趣旨）。自社構成への影響を検証したうえで適用してください。 - 境界側の緩和：WAF やリバースプロキシで SAML エンドポイントへの異常に大きな／高頻度なリクエストを制限する、レート制限をかける、といった多層防御も併用できます（ただし根本対処はアップデートです）。
脆弱性対応の進め方そのものに不安がある場合は、IPA の「脆弱性対策」や「中小企業の情報セキュリティ対策ガイドライン」といった公的指針が判断のよりどころになります。まずはこうした一次情報にあたるのが近道です。
現場目線の所感
正直なところ、SAML のように「導入したら普段は意識しない」認証基盤ほど、この種の脆弱性は見落とされがちです。Spring Boot のバージョンは追っていても、内部で使っている Spring Security の細かなバージョンや、SAML のバインディング方式まで即答できる担当者は多くないはずです。しかも今回は「OSS では 6.5／7.0 系しか無償で直せない」という現実があり、古いラインで塩漬けにしているアプリほど、アップデートの工数と回避策のどちらを取るかという厳しい判断を迫られます。DoS は「情報が漏れないから後回し」と見られがちですが、ログイン基盤が落ちれば全社の業務が止まります。可用性への攻撃こそ、優先度を落としすぎない冷静さが要るところです。
まとめ
- CVE-2026-40988 は、Spring Security の SAML 2.0（REDIRECT バインディング）で圧縮ペイロードの展開を悪用される DoS 脆弱性。認証前・遠隔で悪用可能。
- 影響は 5.7〜7.0 系の広範囲。OSS で直せるのは 6.5.11／7.0.6、それ以前は有償サポート限定のため、移行または回避策の検討が必要。
- まずは「Spring 製アプリで SAML SSO を使っているか」を棚卸しし、修正版適用か、GET 経由レスポンスの無効化などの回避策を選ぶ。DoS でも認証基盤への影響は軽視しない。
関連記事
出典
- Spring（VMware）公式アドバイザリ：CVE-2026-40988
- JVN iPedia：JVNDB-2026-019714
- NVD：CVE-2026-40988
