Struts 2の新しい脆弱性は、2.3系と2.5系では直らない｜「もう修正が来ない」という費用の話

結論：CVSSの数字より、「修正されません」という一行のほうが重い

2026年8月25日、JPCERT/CCとIPAが運営するJVNは、Apache Struts 2のリソース枯渇の脆弱性CVE-2026-73635を公表しました（JVN#08517956）。CVSS 4.0の基本値は8.7、CVSS 3.0では7.5です。

JVNが「影響を受けるシステム」として挙げているのはバージョン6.0.0から6.10.0、および7.0.0から7.2.1で、修正版は7.3.0と6.11.0です。ここまでなら、通常のバージョンアップで対応が完結する話です。

問題は、JVNの対策欄に続けて書かれている次の記載です。

下記バージョンにも本脆弱性が存在しますが、サポートが終了しているため修正されません。 バージョン2.0.0から2.3.37 バージョン2.5.0から2.5.33

この記事は、Struts 2で構築された基幹Webシステムや会員サイトを抱えている中堅企業の経営者・システム責任者に向けています。技術的な深掘りではなく、「修正が来ない状態を持ち続けることは、経営上どういう費用なのか」を扱います。

公表内容

Apache Software Foundationのアドバイザリ（S2-074）は、リクエストのロケールがメッセージの参照に使われる際に、フレームワーク内部のローカライズドテキストのキャッシュが際限なく増大し、Javaヒープを使い果たして他の利用者へのサービス提供を妨げる、と説明しています。攻撃者は認証を必要としません。

深刻度の評価が割れている点をどう読むか

この脆弱性については、評価が一致していません。Apache Software Foundation自身はSeverityを「Moderate」としている一方、JVNが掲載しているCVSS 4.0の基本値は8.7で、これは一般に「重要」と分類される水準です。

矛盾ではありません。Apacheが「Moderate」とした理由はアドバイザリに書かれていないため、その判断根拠をここで説明することはできません。確認できるのは、両者が別の尺度で評価しているという事実だけです。CVSSは、未認証で、複雑な条件なしに、可用性へ高い影響を与えられるという性質を機械的にスコアへ反映します。この脆弱性は情報漏えいも改ざんも伴わず、影響は可用性に限られます（CVSS 3.0のベクタもC:N/I:N/A:H）。

経営判断としては、どちらの評価を採用するかを議論しても意味がありません。判断すべきは「自社のそのシステムが止まったとき、いくらの損失が出るか」です。受注を受け付ける画面なら、止まっている時間がそのまま機会損失です。社内の申請システムなら、業務は止まっても売上は止まらないかもしれません。同じ脆弱性でも、置かれている場所によって重さが変わります。

CVSSだけでは、自社の緊急度は決まりません。スコアは技術的な深刻度を示す有用な材料ですが、そこに自社の業務事情は入っていません。緊急度は、そのシステムが止まったときの影響と組み合わせて判断します。

まず確認する3つのこと

1. 自社のStrutsのバージョン

6.0.0〜6.10.0または7.0.0〜7.2.1なら、修正版（6.11.0または7.3.0）への更新が対応です。2.3系または2.5系なら、この脆弱性に対する修正は提供されません。

バージョンが分からない場合、それは開発ベンダーに問い合わせる事項です。あわせて構成情報の提供を求めてください。

2. struts.localeを使っているか

JVNとApacheの双方が回避策として挙げているのが、struts.locale定数で固定のロケールを設定することです。すでにこの設定を使っている場合、本脆弱性の影響を受けないとされています。

ただし、この設定が効くのは今回のCVE-2026-73635に限った話だということを忘れないでください。設定で回避できたからといって、サポート切れバージョンを使い続けてよいという話にはなりません。次の脆弱性が同じ方法で回避できる保証はどこにもありません。

3. そのシステムが外部から到達できるか

未認証で悪用可能な脆弱性なので、インターネットに公開されているかどうかで実際のリスクは大きく変わります。ただし、社内限定であっても、社内の端末が乗っ取られれば同じ経路になります。「公開していない」は時間を稼ぐ材料であって、対応しない理由ではありません。

「サポート切れ」が意味していること

Struts 2の2.3系と2.5系は、すでにサポートが終了しています。今回の公表は、その状態が具体的に何を意味するのかを、あらためて示しました。

サポート切れとは、「古いソフトウェアを使っている」ということではありません。今後見つかる脆弱性について、公式の修正を継続的に受け取れる保証がないということです。今回のCVE-2026-73635について、JVNは2.3系・2.5系ではサポート終了のため修正されないと明記しています。同じことが次回も起きない、という根拠はどこにもありません。

この違いは、社内の説明でよく混同されます。「古いけれど動いているから問題ない」という説明は、動作の話をしています。しかしリスクの話は、動作ではなく、将来の修正の有無に関するものです。

現時点で、2.3系・2.5系を使っている企業が取りうる主な方向は次の3つです。

当面の対応として選ばれやすいのは2番目と3番目の組み合わせでしょう。それ自体は誤りではありません。誤りになるのは、その状態を「対応済み」と記録してしまうことです。回避策と隔離は、修正を受け取れないという根本の状態を変えていません。記録上は「暫定対応中」であり続けるべきものです。

サポート切れフレームワークの「本当の費用」

刷新の稟議で最も説明しづらいのは、費用対効果です。「今は動いているのに、なぜ数千万円かけて作り直すのか」という問いに、事故のリスクだけで答えようとすると、話が「起きるかどうか分からないこと」の議論になって決着しません。

そこで、実際に毎年発生している費用のほうを数えてみることをおすすめします。サポート切れのフレームワークを抱えている企業では、次のような費用が継続的に発生しています。

判断コスト

脆弱性が公表されるたびに、自社が該当するか、回避できるか、隔離で足りるかを判断する作業が発生します。1回あたりは数時間でも、頻度が上がれば無視できません。しかも、この判断は「直せない」という結論に向かって毎回やり直されます。

説明コスト

取引先のセキュリティチェックシート、監査、保険の更新、入札の要件確認。そのたびに、サポート切れの状態をどう説明するかを考える必要が出ます。近年、取引先から求められる水準は上がる方向にあります。

選択肢の制約コスト

古いフレームワークに縛られていると、新しい機能の追加、外部サービスとの連携、クラウドへの移行といった判断のたびに、「今の基盤で実現できるか」という制約が先に来ます。やりたいことよりも、できることの範囲で計画を立てることになります。

人材コスト

古い技術を扱える技術者は、時間とともに確保しづらくなります。開発ベンダー側の要員配置も同様です。これは単価の問題であると同時に、対応スピードの問題でもあります。

これらは会計上「システム保守費」として一括りにされ、個別には見えません。刷新の判断をするなら、まずこの内訳を分解して数えるところから始めるのが実務的です。

刷新か、延命か、を決めるための5つの質問

刷新すればよい、という単純な話でもありません。残存耐用年数、業務の変化、投資余力によっては、延命が合理的な場合もあります。次の5つに答えると、方向が見えてきます。

1. そのシステムは、今後何年使う予定か。3年以内に業務側で置き換えの計画があるか。
2. 止まったとき、1日あたりいくらの損失になるか。誰が困るか。
3. 現在のバージョンで、どこまで到達を制限できているか。その制限は誰が維持しているか。
4. 取引先や監査から、システムの構成について問われたことがあるか。今後問われる見込みはあるか。
5. 機能追加の要望が、過去2年で何件、技術的な理由で見送られたか。

5番目が刷新の判断で最も効きます。事故のリスクは想像上の話になりがちですが、見送られた要望は実際に起きた損失です。それが積み上がっているなら、刷新は防御ではなく投資として説明できます。

移行の見積もりを比較可能にする「3つの分け方」

刷新の方向で動き出すと、次に困るのが見積もりです。複数社に依頼しても、金額の幅が大きく、何が違うのか分からない、という状態になりがちです。

原因は、移行という作業が単一のものではないからです。依頼するときに、次の3つを分けて見積もってもらうと、比較の軸ができます。

そのまま移す部分

動作の仕方を変えず、新しいバージョンで動くようにするだけの部分です。ここは工数の見積もりが比較的安定します。各社の見積もりがこの部分で大きく割れるなら、対象範囲の理解に差があります。

直す部分

新しいバージョンでは同じ書き方が使えない、あるいは推奨されない箇所です。ここは調査してみないと量が確定しないため、各社とも見積もりに幅を持たせます。幅の持たせ方をどう説明するかが、そのベンダーの見積もり精度を測る材料になります。「調査後に確定します」とだけ書かれた見積もりは、比較の対象になりません。

作り替える部分

移行を機に、業務の変化にあわせて作り直す部分です。ここは技術の話ではなく、業務側の意思決定です。発注側が決めていないと、各社が各社の想定で見積もります。金額差の多くは、実はここから生まれます。

3つに分けたうえで、3番目については「今回はやらない」と明示するだけでも、見積もりの比較可能性は大きく上がります。移行と改善を同時にやるか、分けてやるかは、費用だけでなくリスクの観点でも判断が分かれる論点です。

なぜ2系がいまだに残っているのか

技術的には、とっくに移行しているべきものです。それでも残っている背景には、たいてい業務側の事情があります。

多いのは、そのシステムが「動いていることだけが求められている」状態にあるケースです。新しい機能が要望されず、業務も変わらず、担当者も固定されている。この状態では、投資の理由が社内から出てきません。誰も困っていないので、議題にすら上がりません。

もう1つは、作った当時の担当者も、開発したベンダーの担当者も、すでにいないケースです。仕様書が残っていない、あるいは残っていても実装と一致していない。この状態では移行の見積もりを取ることすら難しく、見積もりが取れないので判断もできない、という循環に入ります。

どちらの場合も、着手の最初の一歩は移行ではありません。現行システムが何をしているのかを、動いている実物から書き起こす作業です。画面の一覧、外部との接続、バッチ処理、権限の種類。この棚卸しがあれば、移行するにせよ延命するにせよ、判断の材料が揃います。棚卸しは移行を決めてから始めるものではなく、決めるために必要なものです。

GXOに相談できること

• 現行システムの構成棚卸し（フレームワーク・ライブラリ・ミドルウェア・OSのバージョンとサポート状況）
• サポート切れ資産の一覧化と、到達経路・暫定対応の整理
• 刷新・部分刷新・延命の比較検討（費用、期間、移行リスク、業務影響）
• 移行範囲と据え置き範囲を分けたうえでの、発注単位の切り出し

現行システムの選択肢を整理する

FAQ

DoSだけなら、情報が漏れるわけではないので後回しでよいですか

情報漏えいがないことは事実です。ただし判断の基準は、脆弱性の種類ではなく、そのシステムが止まったときの自社への影響です。受注、決済、予約、出荷指示に関わる画面であれば、停止は直接の損失になります。社内向けの参照系であれば、優先度は下がります。同じ脆弱性でも結論は変わります。

struts.localeを設定すれば、もう対応しなくてよいですか

この脆弱性については影響を受けないとされています。ただし、それはこの1件についての話です。サポートが終了しているバージョンでは、今後公表される脆弱性に修正が提供される保証がありません。回避策の適用は暫定対応であり、恒久対応ではないという整理を、社内の記録に残しておいてください。

6系から7系へ上げるべきですか

今回の脆弱性への対応という意味では、6.11.0への更新でも7.3.0への更新でも対応できます。どちらを選ぶかは、現在のバージョン、アプリケーションの改修量、今後のサポート期間、開発ベンダーの体制を踏まえて判断する事項です。この記事の範囲では、どちらが良いとは言えません。

WAFを入れれば対応になりますか

Apacheが示している回避策はstruts.locale定数による固定ロケールの設定だけで、WAFは公式の回避策として挙げられていません。今回の脆弱性はリクエストのロケール情報にもとづくキャッシュの増大を利用するもので、遮断条件を適切に設計できるかは製品と設定に依存します。WAFを使う場合も、実際に効果があるかを個別に検証したうえで、補助的な緩和策として位置づけてください。

開発ベンダーが「問題ない」と言っています

その判断が何にもとづくのかを聞いてください。原典で確認できる根拠は「バージョンが対象外である」「修正版（6.11.0または7.3.0）へ更新済みである」「struts.locale定数で固定ロケールを設定している」の3つです。これ以外の対応（独自のバックポートなど）を根拠にするなら、その内容と検証結果まで示してもらってください。

「外部に公開していないから問題ない」は、根拠としては不十分です。CVSSのAV:Nはネットワーク経由で悪用可能という意味であり、インターネット公開を条件としていません。社内の端末が侵害されれば、そこが攻撃元になります。公開していないことは露出を下げる要素ではありますが、影響なしと結論づける根拠にはなりません。根拠が示されない「問題ない」は、確認していないことと区別がつきません。

関連記事・サービス

• レガシーシステム刷新
• EOL緊急対応
• レガシー刷新の費用ガイド
• レガシー資産の棚卸しツール
• レガシー刷新の準備度診断

参考情報

• JVN#08517956 Apache Struts 2におけるリソース枯渇の脆弱性（JPCERT/CC・IPA、2026年8月25日公開、2026年8月26日確認、一次情報）
• Apache Struts S2-074（The Apache Software Foundation、2026年8月13日最終更新、2026年8月26日確認、一次情報）

この記事は、脆弱性そのものの解説より、サポート切れという状態をどう費用として扱うかに重心を置いています。自社のバージョンが該当するか、回避策が自社の実装で使えるか、更新して既存の画面が壊れないかは、コードと構成を見なければ判断できません。判定と対応方針は、開発ベンダーの回答とApacheの公式アドバイザリを根拠にしてください。