Javaのウェブアプリケーション基盤として国内でも広く使われてきたApache Struts 2に、サーバのメモリを枯渇させてサービスを停止させられる脆弱性が公表された。JPCERT/CCとIPAが運営する脆弱性情報データベースJVNが2026年8月25日に公開したもので、脆弱性の識別子はCVE-2026-73635。攻撃には認証が不要で、通常のリクエストを送るだけで成立する。脆弱性の深刻度を示す指標であるCVSS v4.0の基本値は8.7と高く、しかもサポートが終了した古いバージョンには修正が提供されない。
「言語設定」がそのままキャッシュを膨らませる
Struts 2は、型変換エラーやバリデーションエラーのメッセージを利用者の言語に合わせて表示するために、ローカライズされたテキストを内部で参照する仕組みを持っている。参照結果はキャッシュに蓄えられ、次回以降の処理を速くする。
問題は、どの言語のメッセージを引くかを決める「ロケール」の出どころだった。開発者がロケールを明示的に固定していない場合、Strutsは受け取ったリクエストに含まれるロケール情報をそのまま使う。Apache Software Foundationのセキュリティ告知S2-074は、この既定の構成では認証されていない外部の利用者がキャッシュを無制限に増大させられると説明している。攻撃者が毎回異なるロケールを名乗ってリクエストを送り続けるだけで、キャッシュの見出しが際限なく増えていき、最終的にJavaヒープ（Javaプログラムが使うメモリ領域）が枯渇して他の利用者にサービスを提供できなくなるという流れだ。
情報が盗まれるわけでも、任意のコードを実行されるわけでもない。CVSSの評価も、機密性と完全性への影響はなく可用性のみが「高」となっている。だが特殊な道具も権限も要らず、通常のHTTPリクエストの形で成立してしまう点が厄介である。
影響を受けるバージョンと、修正されないバージョン
JVNおよびS2-074が挙げる影響範囲は次の通り。
- Apache Struts 2 バージョン6.0.0から6.10.0
- Apache Struts 2 バージョン7.0.0から7.2.1
- バージョン2.0.0から2.3.37（サポート終了）
- バージョン2.5.0から2.5.33（サポート終了）
修正はバージョン7.3.0および6.11.0で行われた。7.3.0以降ではローカライズテキストのキャッシュに上限が設けられ、上限値は`struts.i18n.cacheMaxSize`で調整できる。加えて、リクエスト由来のロケールを実行環境が持つロケールの範囲に限定する`struts.locale.validateRequestLocale`という設定も追加された。ただし後者は既定では無効で、Apacheはこの変更が後方互換であることを明記している。
注意したいのは末尾の2つ、2.x系である。すでにサポートが終了しているため、この脆弱性に対する修正版は提供されない。JVNは最新版へのアップデートを推奨しているが、2.x系を使い続けている環境では、そもそもサポートのないフレームワークで業務システムを動かしている状態そのものを見直す必要がある。
すぐにアップデートできない場合の回避策
Apacheは回避策として、`struts.locale`定数に対応するロケールを設定してロケールを固定する方法を示している。ロケールを固定すればメッセージ参照にリクエスト由来のロケールが使われなくなるため、この脆弱性の影響を受けない。すでに`struts.locale`を設定している環境は、そのままで影響外だとされている。
とはいえ、これは根本的な修正ではなく、攻撃を受ける入口を閉じる措置にすぎない。表示言語をリクエストに応じて切り替える必要がある多言語サイトでは、ロケールの固定が仕様上そのまま採用できないこともある。まずは自社のStrutsのバージョンと`struts.locale`の設定状況を洗い出し、固定できるならすぐ固定し、並行して7.3.0または6.11.0へのアップデート計画を立てる、という二段構えが現実的だろう。
「情報が漏れない脆弱性」を後回しにしていいのか
情報漏えいや遠隔コード実行につながる脆弱性に比べると、DoSの脆弱性は優先度を下げられがちだ。実際、Apache自身の深刻度評価も「Moderate（中）」にとどまっている。しかし、業務が止まることの損失は業種によって大きく変わる。受注、予約、決済、行政手続といった止まってはいけない導線をStrutsで組んでいるなら、可用性への攻撃はそのまま売上や住民サービスの停止に直結する。
さらに、Struts 2は国内の業務システムやウェブサービスで採用が多く、IPAが同フレームワークの脆弱性対策情報を専用ページで継続的に公開してきた経緯もある。裏を返せば、攻撃者から見れば「日本の業務システムを狙うなら押さえておく価値のある的」と捉えられる面もある。認証不要で、リクエストを投げるだけで効くという手軽さは、悪用の敷居を下げる要因になる。
自社サイトがStrutsで動いているかどうかを即答できない、という状況そのものが危うい。使っているフレームワークとそのバージョンを台帳として持ち、脆弱性が公表されたときに「自分たちは該当するのか」を数時間で判定できる体制があるかどうか。今回の一件は、その平時の備えを点検する機会として受け止めたい。
同じ手口に、自社は備えられていますか？