Apache Struts 2.5 サポート終了とCVE-2026-73635：修正パッチが出ない脆弱性にどう向き合うか

Apache Struts 2.5系は、2024年4月30日をもってサポートを終了しました。最終リリースは2023年12月の2.5.33です。それ以降に発見された脆弱性について、修正版が提供されることはありません。

この点が具体的な問題として表面化したのが、2026年に公表されたCVE-2026-73635です。

CVE-2026-73635：修正版が提供されない脆弱性

この脆弱性はCVSS v4.0の基本値で8.7と評価されています。認証を必要とせず、サーバのメモリを枯渇させてサービスを停止に追い込むことが可能とされています。外部に公開されているシステムであれば、攻撃の前提条件が実質的に存在しないということです。

問題は深刻度そのものよりも、その後にあります。2.x系の旧バージョンはすでにサポートを終了しているため、修正版は提供されません。

通常の脆弱性対応であれば、パッチを適用して終わります。今回はその選択肢がありません。稼働を続ける限り、この脆弱性は解消されないまま残り続けます。そして今後新たな脆弱性が見つかっても、同じことが繰り返されます。

日本国内でのApache Strutsの位置づけ

Apache Strutsは、2000年代の日本の業務システム・Webシステムの構築で広く採用されました。IPA（情報処理推進機構）がApache Struts 2の脆弱性対策情報を専用のページで継続的に公開していることからも、国内での導入規模がうかがえます。

過去にはStrutsの脆弱性を契機としてサイトの一時閉鎖に至った事例も報じられており、「サポートが切れたフレームワークを使い続けること」のリスクは、すでに一度国内で顕在化しています。

バージョン	状況
Struts 1系	2013年4月サポート終了（最終リリース1.3.10、2008年12月）
Struts 2.5系	2024年4月30日サポート終了（最終リリース2.5.33、2023年12月）
Struts 6系	サポート継続中
Struts 7系	2024年12月リリース、現行版

企業システムで最も広く使われてきたのは2.5系です。つまり、いま多くの環境が「サポート対象外」の状態にあります。

「バージョンを上げるだけ」では済まない理由

Struts 2.5系から6系への移行は、ライブラリの差し替えでは完了しません。実際には次のような対応が必要になります。

• Javaランタイムの引き上げ（Java 8以上）
• Servlet API 3.1以上への対応
• OGNL式の書き換え
• インターセプタのインターフェース変更への追従
• 静的メソッドアクセスの廃止に伴う実装修正

いずれもアプリケーションコードに直接手を入れる作業です。画面数・アクション数の多い業務システムでは、影響範囲の特定そのものに時間がかかります。

Struts 1系からの移行はさらに事情が異なります。互換性のある移行先が存在しないため、フレームワークの選定からやり直すことになります。

多くの場合、Strutsだけの問題ではない

2000年代に国内で構築された業務システムでは、Strutsが単独で使われているケースはむしろ少数です。Seasar2、SAStruts、S2JDBCといった国産フレームワークと組み合わされている構成が数多く存在します。

Seasar2は2016年9月26日にサポートを終了しています。Strutsの対応を検討する際には、同じシステム内に10年近くサポートが切れたままの基盤が同居していないかを、あわせて確認しておくべきです。

この点については別記事で詳しく扱います。

現実的な選択肢の整理

サポート終了済みのStrutsが稼働している場合、取りうる選択肢は実質的に次の3つです。

1. 暫定的な緩和策で延命する

WAFによる防御や公開範囲の制限で、当面のリスクを下げる方法です。即効性はありますが、脆弱性そのものは残ります。新たな脆弱性が公表されるたびに同じ判断を迫られ、対応コストは積み上がっていきます。

2. サポート対象バージョンへ移行する

Struts 6系・7系への移行です。前述のとおり相応の改修が必要ですが、フレームワークの系統は維持されます。ただし、この対応で解決するのはStrutsの部分だけです。Seasar2など他のサポート終了済みコンポーネントが同居している場合、問題は残ります。

3. アプリケーション全体をモダンな構成へ刷新する

フレームワークの追従ではなく、システムそのものを現行の技術スタックへ移行する方法です。改修規模は大きく見えますが、サポート終了のたびに発生する対応を繰り返さずに済むため、10年単位で見ると総コストが下回るケースがあります。

Strutsに加えてSeasar2やS2JDBCが混在している環境、あるいは稼働開始から15年以上が経過し、構築当時の担当者が残っていない環境では、この選択肢が現実的になります。

業務ロジックを失わずに移行するために

刷新で最も警戒すべきなのは、長年の運用で積み上がった業務ロジックが移行の過程で失われることです。仕様書が現行システムに追いついていないことは珍しくなく、コードだけが唯一の正確な仕様になっている例も多くあります。

日本ビビファイでは、既存のソースコードを解析してシステムの構造と業務ロジックをモデルとして抽出し、そのモデルから新しいアプリケーションを生成するモデル駆動型のアプローチを採っています。業務ロジックを人が読み取って書き直すのではなく、構造として引き継ぐ方式です。

あわせて、移行後のシステムが移行前と同じ動作をすることを、自動テストによって新旧突き合わせで検証します。

まずは現状の把握から

Strutsのバージョン、同居しているフレームワーク、画面数とアクション数、外部公開の範囲。この4点が整理できれば、対応の選択肢と概算規模は見えてきます。

現行システムのソースコードから構造を自動解析し、移行対象の全体像と概算の移行規模をご提示することも可能です。サポート終了済みの環境を運用されている場合は、お気軽にご相談ください。