Struts が標準だった時代
Apache Struts は MVC2 パターンを Java の Web 開発に広めた立役者です。Struts 1 系は2000年代前半に事実上の業界標準となり、その後 Struts 2 系が後継として広く採用されました。 いまも日本の業務システムには、この時代に構築された Struts 製アプリケーションが数多く残っています。
つまり Struts は「失敗作」だったわけではありません。むしろ成功しすぎたために、大量のレガシー資産として現在に引き継がれているのです。問題は、その後の状況の変化にあります。
サポート終了（EOL）の状況
フレームワークを選ぶうえで サポートが継続しているか は最優先級の判断材料です。Struts の現状を整理します。
| 系列 | 状況 | 補足 |
|---|---|---|
| Struts 1.x | EOL | 最終リリースは 1.3.10（2008年12月）。公式に End-Of-Life が宣言済み。 |
| Struts 2.3.x 以前 | EOL | サポート終了済み。脆弱性が出ても公式パッチは提供されない。 |
| Struts 2.5.x | EOL | 2024年4月30日にサポート終了。 |
| Struts 6.x / 7.x | 継続中 | 現行はメンテナンスされている（7.1.1 が2025年10月リリース）。ただし新規採用の選択肢としては主流ではない。 |
⚠️ 「動いているから大丈夫」ではない
EOL のバージョンは、新たな脆弱性が発見されても 公式の修正が出ません。稼働中のシステムが EOL の Struts に依存している場合、それ自体が重大なセキュリティリスクです。多くの現場が Struts 2.5.x 以前で止まっている点に注意が必要です。
重大な脆弱性の歴史
Struts が「危険」という印象を決定づけたのは、リモートコード実行（RCE）につながる重大な脆弱性が繰り返し報告されてきたことです。代表的なものを挙げます。
| CVE | 概要 | 影響 |
|---|---|---|
CVE-2017-5638 |
Jakarta Multipart パーサの不備による RCE。大規模な情報漏えい事件（Equifax）の原因として知られる。 | RCE Struts の名を世間に知らしめた事案。 |
CVE-2024-53677 |
ファイルアップロード機構の不備によるパストラバーサル／ファイルアップロード→RCE。CVSS 9.5（Critical）。 | RCE 2.0.0〜2.3.37（EOL）、2.5.0〜2.5.33、6.0.0〜6.3.0.2 が影響。6.4.0 以降へのアップグレードと新ファイルアップロード機構への移行が必要。 |
重要なのは、これらが 単発の不運ではなく繰り返し起きてきた という点です。攻撃者にとって「Struts は狙えば刺さる」対象になっており、EOL バージョンを使い続けることのリスクは年々高まっています。
💡 CVE-2024-53677 の教訓
この脆弱性は EOL の 2.5.33 では公式パッチが提供されません。「とりあえずパッチ当てて延命」という選択肢すら塞がれつつあり、サポート対象バージョンへの更新、ひいては別フレームワークへの移行が現実的な対応になります。
設計思想のミスマッチ
セキュリティやEOLは「外的な理由」ですが、設計思想という「内的な理由」も移行が語られる背景にあります。
- XML 中心の設定：Struts は
struts-config.xml/struts.xmlによるアクション定義を前提とします。現代の主流は、アノテーションや自動構成（auto-configuration）によって設定量を減らす方向に進みました。 - DIコンテナとの統合が後付け：依存性注入（DI）やテスタビリティが設計の中心に据えられた Spring 系に対し、Struts はそこが弱い、あるいは後付けになりがちです。
- エコシステムの停滞：周辺ライブラリ・解説記事・新規の知見が増えにくく、トラブル時に得られる情報量が新世代に比べて少なくなっています。
- クラウドネイティブ非対応：起動速度・コンテナ親和性・メトリクス連携といった現代的な運用要件は、Struts が想定していなかった領域です。
「悪い」のではなく「時代が変わった」
ここまでを踏まえても、Struts は「設計が間違っていた」わけではありません。当時のベストプラクティスを体現した優れたフレームワークでした。 変わったのは 周囲の前提 です。設定よりも規約、XMLよりもアノテーション、モノリスよりもクラウドネイティブ、そして継続的なセキュリティ更新が当たり前という時代になりました。
だからこそ本シリーズは Struts を「批判の対象」ではなく、なぜ移行が必要かを映す鏡として扱います。新世代フレームワークが何を解決したのかは、Struts を起点に見ると理解しやすいのです。