Spring Framework 7.0.8が公開されました。今回のリリースは、通常の機能改善やバグ修正に加えて、16件のCVEを修正したセキュリティ重視のメンテナンスリリースです。
WebSocket、Spring MVC、Spring WebFlux、静的リソース、マルチパートリクエスト、SpEL、URI処理、Jackson JMSコンバーターなど、Webアプリケーションの広い範囲に関係する脆弱性が含まれています。Spring FrameworkやSpring Bootを本番環境で利用しているチームは、単にリリースノートを確認するだけでなく、自社アプリケーションがどの機能を利用しているかを起点に、影響調査と更新計画を進める必要があります。
今回のリリースで修正された脆弱性
修正対象は以下のように分類できます。
- WebSocketセッションIDの予測やSockJSセッションに関する問題
- WebFluxにおけるセッション固定攻撃やマルチパート処理を利用したDoS
- Spring MVC／WebFluxの静的リソースにおける情報漏えい、パストラバーサル、オープンリダイレクト
- JavaScriptUtilsやJSP Form Tagsを介したXSS
- AntPathMatcher、SpELに対するDoSやアルゴリズムDoS
- SpELによる任意メソッド呼び出しやキャッシュの無制限増加
- Spring MVC／WebFluxのマルチパート・リクエスト・スマグリング
- UriComponentsBuilderに関するSSRF
- Jackson JMSコンバーターにおける安全でないデシリアライゼーション
特に注意したいのは、認証・認可の実装だけでは防ぎにくい脆弱性が複数含まれている点です。攻撃者が細工したHTTPリクエスト、URI、フォーム、式、WebSocket接続などを送信するだけで、可用性低下や情報漏えい、意図しない処理の実行につながる可能性があります。
利用機能別に見る確認ポイント
Spring MVC／WebFlux
静的リソースの配信、バージョン付きリソース、ファイルアップロード、リダイレクト、URI組み立てを利用しているアプリケーションは優先的に確認します。
静的リソースでは、公開ディレクトリの設定が適切でない場合、パストラバーサルやキャッシュを通じた情報漏えいの影響を受ける可能性があります。WebMvcConfigurerやWebFluxConfigurerで独自のリソースロケーション、リソースリゾルバー、バージョニング処理を設定している場合は、標準設定との差分も確認してください。
ファイルアップロードを受け付けるAPIでは、マルチパート処理に関するDoSやリクエスト・スマグリングのリスクが重要です。Spring Frameworkの更新に加え、リバースプロキシ、ロードバランサー、WAF、アプリケーションサーバー間でContent-LengthやTransfer-Encodingの解釈が一致しているかも確認する必要があります。
WebSocketとSockJS
WebSocketを利用するシステムでは、セッションIDの生成方式や認証済みユーザーとの関連付けを確認します。今回のリリースではWebSocketセッションに関する修正に加え、JdkIdGeneratorへの切り替えやSockJSのプリンシパルチェック改善も行われています。
チャット、通知、リアルタイム監視などでWebSocketやSTOMPを利用している場合は、接続時の認証、接続先の認可、セッションIDのログ出力、再接続時のセッション取り扱いを見直してください。セッションIDやアクセストークンをログに残している場合、更新を機にマスキング状況も確認するとよいでしょう。
SpEL
今回のCVE群ではSpEL関連の修正が目立ちます。SpELを単なる設定記述に使っているだけでなく、ユーザー入力や外部データを式として評価している場合、任意メソッド呼び出しやDoSにつながる可能性があります。
次のような実装は特に調査対象です。
- リクエストパラメータやHTTPヘッダーをSpEL式として評価する
- 管理画面から入力した条件式を実行する
- 動的な認可ルールや検索条件を式で組み立てる
StandardEvaluationContextを利用し、広い型・メソッドアクセスを許可している- 式のパターンや評価結果を独自にキャッシュしている
不要な型参照やメソッド呼び出しを許可しないこと、入力を式として評価せず明示的なデータ構造に変換することが基本的な対策です。今回の更新ではSpEL評価中の操作追跡、エラーメッセージ、パターンキャッシュの改善も含まれているため、更新後に式評価を使う主要ユースケースを回帰テストしてください。
URI生成と外部アクセス
UriComponentsBuilderを使って外部URLやリダイレクト先を組み立てているコードでは、SSRFの影響を確認します。ユーザーが指定したホスト名、スキーム、ポート、パスをそのまま利用している場合、内部ネットワークやクラウドメタデータサービスへのアクセスに悪用される可能性があります。
対策として、許可するスキームとホストを明示的に限定し、DNS解決後のIPアドレスも検証します。URLの文字列比較だけでは、リダイレクト、IPv6表記、ユーザー情報付きURL、DNSリバインディングなどを見落とすことがあります。フレームワーク更新後も、アプリケーション側の許可リストとネットワーク制御を併用してください。
JMSとデシリアライゼーション
Jackson JMSコンバーターを利用してメッセージをJavaオブジェクトへ変換している場合は、デシリアライゼーション設定を確認します。信頼できない送信元から受け取ったメッセージを、型情報付きで無制限にオブジェクト化する設計は危険です。
メッセージ送信元を認証・認可し、受け入れる型を限定することが重要です。JMSブローカー、コンバーター、Jacksonの設定を個別に確認し、テスト環境で想定外の型や不正なペイロードを送信した場合の挙動を検証してください。
Spring Boot利用者が確認すべきこと
Spring Bootアプリケーションでは、Spring Frameworkのバージョンを直接build.gradleやpom.xmlで指定していないケースが多く、Spring Bootの依存関係管理に委ねられています。そのため、Spring Framework 7.0.8を使いたい場合でも、まず利用中のSpring Bootが対応するFrameworkバージョンを確認する必要があります。
確認手順の例は次のとおりです。
- 現在のSpring Boot、Spring Framework、Spring Securityの実効バージョンを確認する
- Spring Framework 7.0.8を取り込めるSpring Bootのリリースや対応表を確認する
- MavenやGradleの依存関係ツリーで、推移的に古いSpringモジュールが残っていないか調べる
- Spring Bootのアップグレードが必要な場合は、Java、Servletコンテナ、Hibernateなど周辺依存関係の互換性を確認する
- 検証環境でテストを実行し、問題がなければ段階的に本番へ展開する
Mavenではmvn dependency:tree、Gradleでは./gradlew dependenciesや依存関係レポートを使い、spring-core、spring-web、spring-webmvc、spring-webflux、spring-messagingなどがどのバージョンで解決されているかを確認します。SBOMやSCAツールを利用している場合は、CVEの検知結果が更新後に解消されることも確認してください。
ただし、セキュリティ修正だけを目的にSpring Frameworkの一部だけを無理に上書きする方法は、互換性問題を引き起こす可能性があります。Spring Bootの管理する依存関係を尊重し、公式にサポートされる組み合わせでアップデートするのが原則です。
更新時の実務チェックリスト
更新作業では、次の項目を最低限確認します。
- 本番で使用しているSpring BootとSpring Frameworkの実効バージョン
- MVC、WebFlux、WebSocket、SockJS、STOMPの利用有無
- ファイルアップロードやマルチパートフォームの受付有無
- 静的リソースの公開場所とバージョン付きリソース設定
- SpELの利用箇所と、外部入力が式評価に入る経路
UriComponentsBuilderを使った外部アクセスやリダイレクト- Jackson JMSコンバーターと信頼できないメッセージの受信有無
- リバースプロキシやWAFを含むHTTPリクエスト解釈の差異
- セッションID、認証情報、内部URLがログやエラーレスポンスに出ていないか
- 依存関係スキャンとSBOMの結果
- 更新前後の負荷試験、回帰テスト、脆弱性再スキャン
特に、インターネットから直接アクセスされるAPI、管理画面、ファイルアップロード機能、外部URLを取得する機能、リアルタイム通信機能を持つシステムは優先度が高いと考えられます。
緊急度の判断
16件すべてが全アプリケーションに同じ影響を与えるわけではありません。影響を受ける機能を使っていない場合、直ちにサービス停止が必要とは限りません。一方で、Spring Frameworkは広く利用される基盤コンポーネントであり、アプリケーションから明示的に呼び出していない内部処理が、Spring Bootや他のライブラリ経由で動作している場合もあります。
したがって、判断は「Springを使っているか」ではなく、「どのモジュールと処理経路を使っているか」で行うべきです。外部公開サービスで該当機能を利用している場合は、通常の定期アップデートを待つのではなく、影響調査、緩和策、パッチ適用を前倒しで進める価値があります。
まとめ
Spring Framework 7.0.8は、16件のCVEを修正した重要なメンテナンスリリースです。影響範囲はWebSocketやWebFluxだけでなく、Spring MVC、静的リソース、SpEL、URI処理、JMSメッセージ変換にまで及びます。
まずは依存関係の実効バージョンを確認し、自社アプリケーションが利用する機能を棚卸ししてください。そのうえで、対応するSpring Bootのバージョンを確認し、検証環境で更新と回帰テストを行います。フレームワークの更新だけで終わらせず、外部入力の式評価、URL検証、ファイルアップロード制限、セッション管理、デシリアライゼーション設定といったアプリケーション側の防御も合わせて見直すことが、今回のリリースを有効なセキュリティ対策につなげるポイントです。