Apache Struts 2 における XML 検証欠如の脆弱性（S2-069、CVE-2025-68493）の概要

Apache Struts 2 における XML 検証欠如の脆弱性（S2-069、CVE-2025-68493）の概要

Apache Struts 2における本脆弱性の概要：名称・種類・深刻度など重要ポイントについての整理

Apache Struts 2の新たな脆弱性「S2-069」（CVE-2025-68493）は、XML入力に対する検証が適切に行われないことで発生する問題です。Struts 2が内部で利用するXWorkコンポーネントにおいて、XMLをパースする際のXML検証の欠如に起因し、外部エンティティを含む細工されたXMLを処理してしまうことで、任意の外部リソースにアクセスされる恐れがあります。この脆弱性はXML外部エンティティ（XXE）攻撃を可能にするもので、機密情報の漏えいやサーバー内ネットワークへの不正アクセス、サービス停止（DoS）など深刻な影響を引き起こす可能性があります。発見者はZAST.AIというAIによる自動解析システムであり、重要度はCVSSスコアで8.8（High）と評価され、Apacheによる分類では“Important”に位置付けられています。なお、本脆弱性はApache Struts 6.1.1で既に修正されており、利用者は早急なアップデートが推奨されます。

CVE-2025-68493とS2-069：識別番号から見る脆弱性の位置付け、Apache Strutsでの重要度評価

脆弱性の識別にはCVE-2025-68493という国際共通の番号と、Apache Strutsプロジェクト独自のS2-069という識別子が用いられています。CVE番号は脆弱性を一意に示すものであり、本件は2025年に報告された68493番目のCVEとして登録されています。一方、S2-069はStruts 2に関する69番目のセキュリティ公告を意味し、Apache公式のセキュリティ情報で参照されます。これらの識別子により、開発者やセキュリティ担当者は本脆弱性の情報を追跡しやすくなります。Apache Strutsは過去にも深刻な脆弱性（例：CVE-2017-5638など）で知られており、それらと同様に本件も重要な問題として扱われています。Strutsのセキュリティ勧告では本脆弱性を“重要（Important）”と格付けしており、システムの機密性や可用性に大きな影響を与える可能性があるため、その位置付けは非常に高いと言えます。

XWorkコンポーネントとは何か：Apache Struts 2の基盤部分の役割と本脆弱性との関係にも注目

Struts 2の基盤となっているXWorkコンポーネントは、アプリケーションのコントローラ部分（アクションの実行や結果処理）を司るフレームワークです。元々はWebWorkフレームワークに由来し、Struts 2に統合されたXWorkは、設定ファイル（struts.xml や xwork.xml など）の読み込みや、アクションマッピング、OGNLによる値のバインディングといった機能を提供しています。XWorkはXML形式の設定を扱うため、XMLパーサを内部で利用しており、今回の脆弱性はまさにそのXML処理部分に起因します。具体的には、XWorkのXML処理において外部エンティティの利用に対する適切な制限や検証がなされていなかったため、攻撃者が細工したXMLを流し込むことで、意図しないリソース参照が実行されてしまうのです。Struts 2の基本構造に深く組み込まれているXWorkで問題が発生したため、本脆弱性はフレームワーク全体に影響を及ぼす結果となっています。

脆弱性発見の経緯と背景：ZAST.AIによる自動検出のインパクト、AI技術による脆弱性発見の新たな潮流

本脆弱性は従来の人間のセキュリティ研究者ではなく、ZAST.AIというAI駆動の自動セキュリティ解析システムによって発見された点が特徴的です。ZAST.AIは機械学習とプログラム解析技術を組み合わせてソフトウェアの脆弱性を検出するプラットフォームであり、人間では見落としていたような古いコード上の欠陥を洗い出すことに成功しました。Apache Strutsのセキュリティチームにこの脆弱性が報告されたのは2025年末で、比較的静かなうちに修正準備が行われ、2026年1月に勧告が公開されています。AIによる脆弱性発見が実用化されたことで、今後は発見スピードの加速が予想されます。組織側にとっては、脆弱性が見つかってから対策を講じるまでの時間がますます重要となり、この事例はAI時代におけるセキュリティ対応の新たな課題とインパクトを示唆しています。また、本件は広く利用されてきたソフトウェアに長年潜在していた脆弱性がAIの力で浮き彫りになった例でもあり、従来からのシステムに対しても継続的な監視とアップデートが必要であることを物語っています。

本脆弱性が注目される理由：Apache Strutsの過去事例と教訓から広く警戒すべきポイントとなっている

Apache Strutsは以前から複数の重大インシデントで注目を集めてきた経緯があり、本脆弱性も発表当初からセキュリティ業界で警戒されています。特に2017年のStruts 2脆弱性（CVE-2017-5638）は大規模情報漏洩事件（Equifax社の事例）の原因となり、Strutsの脆弱性=深刻な被害という印象が強まりました。そのため今回のXML検証欠如の問題も、「またStrutsに重大な欠陥」としてニュースや専門家による解説がなされています。公開直後の段階では幸い大きな混乱は起きていないものの、ApacheやJVNによる注意喚起が早期に行われ、脆弱性の技術的詳細や対策方法が各所で共有されています。しかし、多くの組織ではフレームワークのアップデートに時間がかかる傾向があり、攻撃者はそのラグを突いて悪用を試みる可能性があります。過去の教訓から、組織は本脆弱性を深刻に受け止め、迅速に対処する必要があると広く認識されています。

Apache Struts 2 の XWorkコンポーネントにおける XML 外部エンティティ処理不備が引き起こす脆弱性の原因と技術的概要

XWork内のXML解析処理の問題点：外部エンティティ許可がもたらす脆弱性発生メカニズムの詳細解説を行う

XWorkコンポーネント内のXML解析処理における最大の問題点は、XMLパーサが外部エンティティを受け入れてしまう設定になっていたことです。通常、安全なXML解析を行うには、外部エンティティ参照を禁止するか、DTDなどの外部リソースを読み込まないようにパーサを構成する必要があります。しかしXWorkでは、そのようなセキュアなパーサ設定が施されていないため、攻撃者が細工したXMLに宣言を埋め込んだ場合でも、フレームワークは疑うことなくそれを展開してしまいます。例えば、<!ENTITY xxe SYSTEM "file:///etc/passwd"> のような定義が含まれていれば、XWorkはファイルシステム上の/etc/passwdを読み取ろうとします。このように外部エンティティの許可によって、XML解析処理の段階でアプリケーションの意図しないリソースアクセスが生じ、これが本脆弱性の発生メカニズムとなっています。言い換えれば、XWorkのXML処理コードには入力XMLの内容を厳密に検証するロジックが欠如しており、結果としてXXE攻撃に対して脆弱な状態でした。

XML検証欠如とは何か：バリデーション不足によるXXE脆弱性の意味、技術的に何が欠落しているのかを解説

「XML検証の欠如」とは、文字通りXMLデータの内容や構造をチェックせずに受け入れてしまう状態を指します。本来、XMLをパースする際にはスキーマやDTDに基づいたバリデーション（妥当性検証）を行ったり、危険な要素を無効化したりするべきですが、XWorkではそうした検証プロセスが不足していました。具体的には、外部エンティティ参照やDOCTYPE宣言といった攻撃に悪用されやすいXML機能を許容していたため、入力されたXMLが不正なものであってもストリクトに拒否されなかったのです。結果として、XWorkは提供されたXMLをそのまま処理してしまい、そこに含まれる悪意ある定義を実行してしまいます。つまり、XMLデータに対する入力検証の欠如がXXE脆弱性の本質であり、安全対策として本来必要だったチェックが抜け落ちていたことが問題となりました。なお、このような検証漏れはCWEでCWE-112（Missing XML Validation）として分類されており、セキュリティ上の重大な欠陥です。

XML外部エンティティ(XXE)とは：攻撃手法と影響範囲を理解する、一般的なXXE攻撃の仕組みとその危険性について

XML外部エンティティ（XXE）とは、XML文書内で外部のリソースを参照するエンティティを悪用した攻撃手法です。攻撃者はXMLのDOCTYPE宣言部分に外部エンティティを定義し、そのエンティティをXMLデータ内で利用することで、本来アクセスできない情報を引き出したり、サーバーから任意のURLへリクエストを送信させたりします。例えば、外部エンティティをローカルファイル（前述の/etc/passwdなど）に指向させれば、そのファイル内容がXMLパーサによって読み込まれ、攻撃者がそれを得ることができます。また、外部エンティティをHTTP URLにすれば、サーバーが内部ネットワーク上のサービスやインターネット上のサーバーに対してサーバーサイドリクエストフォージェリ（SSRF）を行うことも可能です。さらに、XXEを利用して膨大なエンティティを再帰的に展開させることで、パーサに過負荷をかけサービス拒否（DoS）状態を引き起こす攻撃（いわゆる「Billion Laughs攻撃」）も知られています。このようにXXEは、データ漏えいからDoSに至るまで幅広い影響範囲を持つ攻撃手法であり、本脆弱性によりStruts 2を用いたシステムはこれらXXE攻撃のリスクに晒されることとなりました。

StrutsフレームワークでXMLを扱う箇所：脆弱性が顕在化する可能性のあるケースを例示し深掘り考察する

Apache Struts 2はフレームワーク内で様々な場面でXMLを扱っています。典型的なのはstruts.xmlやxwork.xmlといったフレームワーク設定ファイルですが、これらは開発者が提供するもので通常は外部から改ざんされることはありません。しかし、Strutsベースのアプリケーションによっては、クライアントからXMLデータを受け取って処理する機能を持つ場合があります。例えば、RESTプラグインを使用したWebサービスでは、リクエストボディとしてXMLが送信され、それをオブジェクトに変換する処理が行われます。こうした箇所に本脆弱性が存在すると、攻撃者はリクエストXMLに外部エンティティを紛れ込ませることで、サーバー側に不正な動作をさせることが可能になります。実際のシナリオとしては、ユーザからアップロードされたXMLファイルを解析する機能や、Web APIでXML形式の入力を受け付ける部分などが該当し、これらが脆弱性の顕在化するポイントとなり得ます。要するに、外部から与えられるXMLをXWorkが処理するようなケースでは、本脆弱性が直接悪用される可能性があるのです。

安全なXMLパーサ設定が欠如した原因：過去コードや設定上の見落としによる脆弱性混入の経緯を詳しく探る

では、なぜXWorkで安全なXMLパーサ設定が行われていなかったのでしょうか。一因として考えられるのは、フレームワークの歴史的経緯や過去コードの見落としです。XWork（およびWebWork）が開発された当初、XML外部エンティティによる攻撃の危険性は現在ほど広く認識されておらず、デフォルトでXMLパーサの外部エンティティを無効化する実装がなかった可能性があります。その結果、その設定が長年にわたりコード中に残存し、脆弱性が温存されてしまったと考えられます。また、開発者側でXMLパーサの挙動に関するセキュリティ検証が十分でなかった（外部エンティティの悪用リスクを想定していなかった）ことも原因でしょう。Struts 2は長期間にわたり進化と改良を続けてきましたが、一部の古い部分にセキュリティ上の穴が埋もれていた形です。この脆弱性の発覚は、フレームワーク開発における安全設定の見落としが重大なリスクを招くことを示す教訓となりました。

影響を受ける Apache Struts 2 および 6 のバージョン一覧とその影響範囲の詳細な解説

脆弱性の影響を受けるバージョン一覧：Apache Struts 2.0.0〜2.3.37、2.5.0〜2.5.33、6.0.0〜6.1.0

今回の脆弱性は、Apache Strutsの非常に広範囲なバージョンに影響します。具体的には、Struts 2.0.0から2.3.37までの旧2.3系統、Struts 2.5.0から2.5.33までの2.5系統、そして最新世代であるStruts 6.0.0から6.1.0までが脆弱性の対象となっています。このリストから分かるように、Struts 2の初期バージョンから最近の6.x系まで、複数のメジャーリリースにまたがって脆弱性が存在していました。なお、Struts 2.3.37以前および2.5.33以前のバージョンは既に開発元からのサポートが終了しているため、実質的にはすべての現役サポート外のStruts 2系と、一時的にサポートされていた6.0系が影響を受けることになります。広範なバージョンに影響が及ぶことから、多くのシステムが潜在的にこの脆弱性のリスク下にあったと言えます。

サポート終了（EOL）となった旧2.x系バージョン：修正提供が望めないリスクに対する注意喚起の必要性

影響範囲に含まれるStruts 2.0〜2.3系および2.5系は、既にEOL（End of Life）を迎えているバージョンです。EOLとなったソフトウェアは開発元からのセキュリティ更新提供が停止しており、今回のような新たな脆弱性が見つかっても公式パッチがリリースされない可能性が高い状態にあります。実際、Struts 2.3系や2.5系に対しては、Apacheは本脆弱性の修正版を提供せず、ユーザに対しては新しいバージョン（6.1.1以上）への移行を促しています。このため、依然としてこれら旧バージョンを使用し続けているシステムでは、脆弱性が恒久的に残存することになり、大きなリスクとなります。特に企業システムでは、古いフレームワークを長期間使い続ける例が珍しくなく、サポート切れのStruts 2系を利用しているケースも多いと考えられます。そうした環境下では、本脆弱性に対する公式な修正手段がないため、利用者自身がアップデートや防御策を講じない限り、リスクが解消されない点に注意が必要です。

Struts 6系バージョンにも及んだ影響：最新ラインにも脆弱性が残存していた原因を詳細に考察する。

興味深い点として、最新のメジャーバージョンであるStruts 6系（6.0.0〜6.1.0）にも本脆弱性の影響が及んでいたことが挙げられます。通常、新バージョンでは過去の脆弱性への対策や古いコードの刷新が行われるものですが、Struts 6でも同じ問題が残存していたのです。これは、Struts 6がStruts 2からフレームワークの基本部分を引き継いでいるためと考えられます。つまり、XWorkのXML処理に関するコードは6.x系に入っても大きく変わっておらず、過去から潜在していた欠陥がそのまま持ち込まれてしまった形です。Struts 6系は2022年以降に登場した比較的新しいラインですが、その初期リリースから本脆弱性を内包していたため、「最新バージョンだから安全」という想定が覆されました。この原因としては、6系へのメジャーアップデートに際してセキュリティ観点での包括的なレビューが行き届かなかったことや、前述のように古いコードの使い回しがあったことが背景にあるでしょう。最新ラインにも脆弱性が存在した事実は、フレームワークのメジャーアップデートにおいても過去からの課題を引きずる場合があることを示しています。

アップデート版6.1.1での修正内容：安全なXML処理の実現と効果を詳細に解説し、改善点を評価する

Apache Strutsの開発チームは、本脆弱性に対応して6.1.1で修正を行いました。バージョン6.1.1では、XWorkを含むフレームワーク内部のXMLパーサ設定が強化され、外部エンティティを読み込まないようにする対策が施されています。具体的な修正内容としては、SAXパーサーファクトリの設定を変更し、外部DTDや外部一般エンティティのアクセスを無効化するフラグを有効にしたものと推測されます。この変更により、従来は許可されていた危険なXML構造が無視されるようになり、XXE攻撃の試みは失敗するようになります。6.1.1へのアップデート後は、フレームワークレベルでXMLの安全な取り扱いが保証され、少なくとも本脆弱性による不正なリソース参照は発生しなくなります。なお、この修正は基本的にアプリケーションの挙動に影響を与えない（外部エンティティを必要とする特殊なケースを除き互換性に問題ない）とされており、セキュリティ向上のために速やかなアップデートが推奨されています。

脆弱性が広範囲に影響した背景：XWorkコードの共有と脆弱性引き継ぎによる全バージョン共通の問題点を考察

これほど広範なバージョンに脆弱性が共通して存在した背景には、Strutsが内部で共有するコード（XWork）の存在があります。Struts 2.0以降からStruts 6まで、フレームワークのコア部分としてXWorkのコードが引き継がれてきました。言い換えれば、XML処理に関するロジックは長年にわたり大きく変更されず残っていたため、その中に潜んでいた問題も全バージョンで共通に引き継がれてしまったのです。過去のいずれかの時点でXML検証の不足に気付き対策がされていれば被害範囲は限定的だった可能性がありますが、結果的に2025年後半まで誰にも発見されなかったために、蓋を開けてみれば複数世代のStrutsにまたがる大規模な脆弱性となりました。これはフレームワーク開発において、基盤コードのセキュリティレビューがいかに重要かを物語っています。共通コンポーネントに潜む1つの欠陥が、長期間にわたり多くのシステムに影響を与え得るためです。Struts開発チームも今回の件を受けて、共有コードの見直しと強化に取り組んでいることでしょう。

Apache Struts 2 の XML 検証欠如の脆弱性による機密情報漏えいの重大な危険性と影響

XXE攻撃でサーバー内部の機密ファイルが読み取られるリスク：設定ファイルやパスワードファイルが狙われる危険性

XXE脆弱性を悪用されると、サーバー内部の機密ファイルが攻撃者に読み取られる危険性があります。例えば、Linuxサーバーであれば/etc/passwdや/etc/shadowといったシステムユーザ情報のファイル、アプリケーションの設定ファイル（データベース接続文字列やAPIキーが記載されたプロパティファイルなど）、ログファイルに記録された個人情報等が標的となり得ます。攻撃者はXXEを利用してこれらのファイルパスを外部エンティティとして指定し、XMLパーサにそれらを読み込ませることで内容を入手できます。実際に機密ファイルの内容が漏洩すれば、そこからさらに攻撃に発展する可能性が高まります。たとえば、設定ファイルからデータベースの認証情報を盗み出された場合、データベースへの不正アクセスや情報改ざんにつながる恐れがあります。このように、サーバー内部に保管された本来外部に公開されないはずのデータが流出する点で、XXE脆弱性は極めて深刻です。

認証情報や構成データの漏洩：システム全体への影響と二次被害、大規模な影響に発展する可能性について解説する

機密情報の漏洩によって引き起こされる影響は、単に情報が第三者に知られるだけに留まりません。漏洩したデータに認証情報（ユーザID・パスワードや秘密鍵など）が含まれていた場合、攻撃者はそれを用いてシステムに不正侵入したり、更なる権限を獲得したりできます。例えば、先述のデータベース接続情報が漏れたケースでは、攻撃者はその資格情報を使って直接データベースにアクセスし、顧客情報の大量窃取や改ざんを行う恐れがあります。また、アプリケーションの設定ファイルからメールサーバの認証情報が漏洩すれば、スパム送信に悪用される可能性もあります。構成データの中には、内部ネットワークの構造や使用中のソフトウェアのバージョンといった攻撃計画に有用な情報も含まれ得ます。そうした情報を手に入れた攻撃者は、より的確な二次攻撃（例えば既知の脆弱性を突く攻撃やソーシャルエンジニアリング）を仕掛けてくるかもしれません。このように、機密情報の漏えいは連鎖的に新たなリスクを生み、システム全体の安全性を脅かす重大な事態へと発展し得るのです。

情報漏えいがもたらす組織へのダメージ：信用失墜や法的リスクの深刻性を解説し、潜在的な長期影響にも言及

機密データの漏えいは技術的な被害にとどまらず、組織や企業に対して甚大なダメージを与えます。まず、顧客情報や個人情報が流出した場合、ユーザの信用失墜に直結します。顧客はその企業のサービス利用に不安を覚え、最悪の場合離れてしまうでしょう。また、企業は情報漏洩に関して法的な責任を問われる可能性があります。個人情報保護法やGDPRといった規制の下では、漏洩事故に対して多額の罰金や制裁措置が科されるケースもあり、経済的損失も大きくなり得ます。さらに、漏洩対応にかかるコスト（原因調査、セキュリティ対策強化、被害者への通知・補償など）や業務停止による損失も発生します。これらの法的リスクや長期的な信用問題は、システムダウンやデータ破壊以上に経営に深刻な影響を及ぼします。一度失われた信頼を回復するのは容易ではなく、組織にとって情報漏洩は避けねばならない最悪の事態の一つと言えます。例えば日本でも、漏洩発生時には個人情報保護委員会への報告義務や社会的な批判が避けられず、企業存続に関わる問題となります。

Webアプリケーションにおける情報漏えいシナリオ：XXE脆弱性が引き起こす具体的な漏洩パターンを考察

Webアプリケーションにおける情報漏えいのシナリオを具体的に見てみましょう。あるStruts 2アプリがXML形式のデータを受け付ける入力機能を持っているとします。攻撃者はその機能に対して、内部ファイルを参照する外部エンティティを埋め込んだ悪意あるXMLを送信します。サーバー側では一見通常通りXMLを処理しますが、実際には攻撃者が指定したファイル（例：/etc/credentials.confなど）を読み込み、その内容をXMLの一部として出力してしまいます。攻撃者はサーバーから返されたレスポンスやエラーメッセージ中に、自分が仕掛けたエンティティによって含まれた機密情報が記載されているのを確認できるでしょう。このようにして、アプリケーションが正常な動作を装ったまま、内部情報が攻撃者に露呈してしまうのです。場合によっては、漏洩に気付かれずに長期間にわたり機密情報が抜き取られる可能性もあり、被害の深刻さが増大します。

過去の類似インシデントから見るXXEによる情報漏えいリスク：教訓から学ぶべき点と再発防止策を考察する

XXEによる情報漏えいリスクは過去にも様々なシステムで問題視されてきました。例えば、2010年代にはXMLパーサの設定不備によるXXE脆弱性が多数報告され、多くのソフトウェアベンダーが対応に追われました。Apache SolrやMicrosoftの旧XMLライブラリなどでも同種の欠陥が見つかり、機密情報が引き出される恐れが指摘されたことがあります。こうした過去の類似インシデントから得られた教訓は、XMLを扱うソフトウェアでは必ず外部エンティティ対策を講じるべきだという点です。今回のStruts 2のケースでも、それが実装されていなかったために大規模な影響範囲となりました。開発者はこれらの教訓を踏まえ、フレームワーク任せにせず、自身のアプリケーションでもライブラリの設定を確認し必要な対策を取ることが重要です。また、脆弱性発見後の対応としては、早急なアップデート適用はもちろん、被害が起きていないか（ログのチェック等）確認し、将来的に同様の問題を防ぐためのセキュリティ監査を実施することが推奨されます。

Apache Struts 2 における XXE の悪用による SSRF・DoS 攻撃のリスクと被害の可能性

外部エンティティが引き起こすサーバーサイドリクエストフォージェリ(SSRF)攻撃の可能性と危険度を解説

XXEによって外部エンティティが悪用されると、サーバーサイドリクエストフォージェリ（SSRF）攻撃の起点にもなり得ます。SSRFとは、脆弱なサーバーを踏み台にしてサーバー自身に任意のHTTPリクエストを送らせる攻撃手法です。本脆弱性の場合、攻撃者はXML内の外部エンティティを内部ネットワーク上のサービスや特定のURLに向けることで、Strutsアプリケーションサーバーにそのリソースを取得させることができます。例えば、クラウド環境ではhttp://169.254.169.254/（AWS EC2のメタデータサービス）へのリクエストをエンティティとして仕込めば、サーバーは自らメタデータ情報を取得して攻撃者に漏らしてしまう可能性があります。また、社内システムのAPIエンドポイント（ファイアウォール内で外部から直接はアクセスできないもの）を指し示せば、攻撃者はSSRFを通じて内部ネットワークの探索や攻撃を進めることができます。このように、XXE脆弱性は単なる情報漏洩に留まらず、サーバーを代理人として別の標的へ攻撃を仕掛ける足掛かりともなり得るのです。

XXEを悪用した内部ネットワークへの不正アクセス例と危険性：ファイアウォール内への侵入シナリオを解説

XXEを利用したSSRF攻撃により、攻撃者は通常は外部から到達できない内部ネットワークへの不正アクセスが可能となります。例えば、社内でのみ利用されるWeb APIやデータベースがある場合、攻撃者はその内部IPアドレス（例：10.x.x.xや192.168.x.x）を外部エンティティとして指定し、Strutsサーバー経由でHTTPリクエストを送信できます。これにより、内部サービスの応答内容を外部から盗み見たり、サービスが稼働しているかを確認（ポートスキャン的に利用）することができます。場合によっては、認証なしで利用できる内部APIから機密データを取得したり、管理用のWebコンソールにアクセスして設定を変更するなど、組織内ネットワークに踏み込んだ攻撃へと発展する恐れもあります。内部ネットワークは通常ファイアウォール等で守られていますが、XXEを悪用したSSRFによってその防御を迂回され、内部の脆弱なシステムが攻撃対象となりうる点で非常に危険です。攻撃者は一度内部に足がかりを得ると、そこからさらに横展開して被害を拡大させる可能性があるため、SSRFリスクは特に警戒すべきものです。

XXEを利用したDoS攻撃：リソース枯渇を狙う攻撃手法と影響を詳しく説明する（Billion Laughs攻撃など）

XXE脆弱性は、システムへのサービス妨害（DoS）攻撃にも利用される可能性があります。典型的な手法は、XMLパーサが処理に膨大な計算資源を消費するような細工をすることです。有名な例として「ビリオンラフ攻撃（Billion Laughs）」が挙げられます。これは、内部エンティティを再帰的に定義し何億もの文字列に展開させることで、XMLパーサのメモリやCPUを過負荷にするDoS攻撃です。Struts 2の脆弱なパーサ設定では、このような攻撃ペイロードを検知・遮断できないため、攻撃者が巨大なXMLを送りつけることでサーバープロセスの応答が極端に遅くなったり、最悪クラッシュしてしまう恐れがあります。XXEを介したDoS攻撃は外部から容易に仕掛けることができ、脆弱なサービスを停止させる強力な手段となり得ます。一度サービスが停止すると、その間の業務やサービス提供が不能となり、ユーザに影響を与えるのはもちろん、システム復旧のための対応にも時間とコストを要します。特に重要なシステムにおいては、わずかな停止でも甚大な被害となりかねないため、DoSリスクも軽視できません。

サービス運用妨害(DoS)がビジネスに与える影響：ダウンタイムと信用問題のリスクを詳細に分析し考察する

サービス運用妨害（DoS）攻撃によるダウンタイムは、企業やサービス提供者にとって大きな打撃となります。例えば、オンラインショップや金融取引サイトが数時間ダウンするだけでも、売上損失や顧客からの信頼低下に直結します。DoS攻撃の場合、明確な情報漏えいは発生しなくとも、サービスが利用不能になることで利用者に多大な不便を強いることになり、ブランドイメージの悪化を招きかねません。また、SLA（サービス品質保証）を設けている場合には、長時間のダウンタイムにより違約金や補償が発生することも考えられます。ビジネスへの影響としては、短期的な収益減少だけでなく、継続的な顧客離れや競合他社への乗り換えといった信用問題へ波及する可能性があります。DoS攻撃は比較的簡単に実行できるため、攻撃者が身代金要求（Ransom DDoS）のような手段で企業を脅迫するケースも報告されています。このように、DoSによるサービス停止は経営面でも無視できないリスクであり、脆弱性を放置することはビジネス継続性の観点から非常に危険です。

SSRFとDoSの複合攻撃リスク：同時多発的な攻撃シナリオへの警戒と対策の必要性・重要性の高さを解説する

本脆弱性はSSRFとDoSという二つの脅威を併せ持つため、攻撃者は状況に応じて複合的な攻撃シナリオを描くこともできます。例えば、まずSSRF手法で内部ネットワークの情報収集を行い、脆弱な内部システムや機密データを把握した上で、その証拠隠滅やさらなる混乱を狙ってDoS攻撃を仕掛けるといった連携が考えられます。実際のサイバー攻撃では、一つの手口に留まらず複数の攻撃ベクトルを組み合わせて被害を最大化するケースが多く見られます。SSRFとDoSの組み合わせは、情報窃取とサービス妨害を同時多発的に引き起こす最悪のシナリオとも言え、防御側にとって非常に対応が難しい状況を作り出します。攻撃者視点では、DoS攻撃で監視の目を引き付けている間に、静かにSSRFでデータを抜き取るなど、複数の攻撃を時間差で仕掛けることも可能でしょう。したがって、組織としては本脆弱性を放置することで複合攻撃の餌食となるリスクがあることを認識し、早急に対策を講じる必要があります。

Apache Struts 2 の XXE脆弱性を悪用した被害シナリオの具体例：ローカルファイル読み取りや内部ネットワークアクセスなど

悪意あるXMLペイロードでサーバー上の重要ファイルを窃取する具体的な攻撃シナリオと手口の例として紹介する

ある攻撃シナリオとして、攻撃者が悪意あるXMLペイロードを送りつけてサーバー上の重要ファイルを窃取するケースを考えてみましょう。攻撃者はまず、ターゲットとするファイル、例えば/etc/secret.token（アプリの認証トークンが保存されていると仮定）へのパスを、外部エンティティとして定義したXMLを用意します。このXMLをアプリケーションの入力受付機能（例えばファイルアップロードやWebサービスのリクエスト）に投入すると、脆弱なXWorkパーサがエンティティ参照を解決し、サーバー内部の/etc/secret.tokenファイル内容を読み取ってしまいます。さらにその内容が何らかの形で攻撃者に返却されるか、エラーログ等に記録された場合、攻撃者は秘匿情報（トークンの値）を入手することに成功します。このトークンを使えば攻撃者はアプリケーションの他のAPIを正規ユーザになりすまして呼び出すことができ、システムの不正利用やデータ窃取をエスカレートさせる可能性があります。このシナリオでは、表向きは単にXMLをやり取りしているだけで管理者からは異常に見えないため、攻撃が検知されにくい点も厄介です。

XXE経由で内部システムに不正アクセスする例：データベースや社内APIへの攻撃可能性について解説する

別のシナリオとして、XXEを介して社内の重要システムに不正アクセスする例が考えられます。攻撃者は外部エンティティをHTTP経由で社内システムのAPIに向けることで、StrutsサーバーにそのAPIを呼び出させます。例えば、社内に認証なしでアクセス可能なバックエンドAPIが存在し、機密データを返すエンドポイントがあったとします。攻撃者はXML内で<!ENTITY intranet SYSTEM "http://192.168.0.5:8080/api/secretData">のような宣言を行い、それを参照することで、Strutsサーバーに192.168.0.5上のサービスからデータを取得させます。取得したデータはそのままXMLレスポンスに組み込まれ攻撃者の元へ届く可能性があります。あるいは、内部の管理用Webインターフェースに対し特定の操作を行うリクエストを送信させ、設定変更やユーザアカウント作成といったアクションを密かに実行させることも理論上は可能です。これらは極端な例に思えるかもしれませんが、実際に過去の攻撃ではSSRFを用いてクラウド環境のメタデータ取得や内部システムへの侵入が報告されており、XXE脆弱性はそうした内部不正アクセスの糸口となり得るのです。

クラウド環境におけるSSRF攻撃：AWS EC2メタデータサービスを標的とした情報窃取シナリオを解説する

クラウド環境では、SSRF攻撃の一つの典型的なターゲットがクラウドメタデータサービスです。AWSを例にすると、インスタンス内部からhttp://169.254.169.254/latest/meta-data/にアクセスすると、そのサーバーのIAMロール認証情報や設定情報が取得できてしまいます。攻撃者はXXE脆弱性を利用して、Strutsアプリケーションサーバーにこの特殊なアドレスにリクエストさせ、AWSアクセスキーやシークレットキーを含むメタデータを入手することを狙います。取得した資格情報を用いれば、攻撃者はクラウド上でそのサーバーに与えられていた権限の操作（データストレージへのアクセスや他のインスタンスの操作など）を自在に行えてしまいます。これは非常に危険なシナリオで、実際に2019年頃にはCapital One銀行の事例など、クラウドメタデータサービスのSSRFにより大規模な情報漏洩が発生しています。Struts 2のXXE脆弱性は、このようなクラウド特有の攻撃ベクトルにも利用され得るため、オンプレミス環境のみならずクラウド上でStrutsを運用している場合も十分な注意が必要です。

膨大なエンティティ展開を悪用したDoS攻撃：ビリオンラフ攻撃によるサービス停止の再現例を詳細に分析する

XXE脆弱性を利用したDoS攻撃シナリオも具体的に見てみます。攻撃者は大量のエンティティ参照が入れ子になった「ビリオンラフ」ペイロードを用意し、それをアプリケーションに送信します。例えば、<!ENTITY lol1 "lol">から始まり、lol2はlol1を9回展開、lol3はlol2を9回、といった具合に指数関数的にエンティティを定義した巨大XMLです。脆弱なサーバーはこれを真面目にパースしようとしてしまい、メモリ使用量が急増、CPU使用率も100%に張り付きます。結果として、正当なユーザからのリクエストに応答できなくなり、システムは事実上ダウンした状態になります。ログには異常なXML処理に関するエラーが大量に出力されるものの、直接的な原因箇所の特定は難しく、管理者が気付いて再起動等を行うまでサービス停止が続くでしょう。この再現例が示すように、攻撃者は一度のリクエストでサーバーを麻痺させることが可能であり、従来の容量型DDoS攻撃とは異なるアプリケーション層の脆弱性悪用によるDoSは、防御策を講じていないと非常に厄介です。

複数の攻撃ベクトルを組み合わせた高度なXXE悪用シナリオ：継続的な攻撃への備えと対策の必要性を検討する

高度な攻撃シナリオとして、XXE脆弱性を軸に複数の手口を組み合わせたケースを想定してみます。攻撃者はまず、本脆弱性を利用して内部情報を収集（SSRFによるネットワーク探索や機密ファイルの窃取）し、システムの弱点や重要データを把握します。次に、得られた情報（例えば管理者アカウントのパスワードや内部サーバの構成）を元に別の攻撃を仕掛け、システムにさらなる侵害を加えます。例えば、SSRFで取得したクラウド認証情報を用いてクラウド環境全体に攻撃範囲を拡大したり、内部で見つけた脆弱なサービスに対して別のエクスプロイトを実行するかもしれません。そして最終段階では、痕跡を消すあるいは防御対応を妨害する目的でDoS攻撃を発動し、システム管理者が対処に追われている隙にデータを抜き取り続ける、といった同時多発攻撃も考えられます。このようなシナリオは現実に起こり得るものであり、巧妙な攻撃者は一つの脆弱性から縦横無尽に攻撃範囲を広げます。したがって、開発者やセキュリティ担当者はXXE脆弱性を「単独の穴」ではなく複合的リスクと捉え、包括的な防御戦略を講じる必要があります。

開発者が取るべき対策：Apache Struts 6.1.1 へのアップデートとワークアラウンドの適用

脆弱性修正済みバージョン6.1.1へのアップデートが最優先の対策：直ちに最新版への移行を推奨すること

開発者やシステム管理者が真っ先に取るべき対策は、脆弱性が修正された最新版（Struts 6.1.1）へのアップデートです。Apache Strutsの公式発表でも6.1.1以上へのアップグレードが最優先事項として強調されています。6.1.1には前述の通りXMLパーサの安全設定が反映されており、このバージョン以降を使用すれば当該XXE脆弱性によるリスクは解消されます。アップデート作業にあたっては、フレームワークのメジャーバージョン移行（2系から6系への移行）を伴う場合がありますが、セキュリティの観点では多少の開発コストよりも安全性確保が優先されるべきです。脆弱性公表直後は攻撃コード（エクスプロイト）が公開されていない場合でも、時間の経過とともに広く知られ悪用されるリスクが高まります。そのため、パッチが入手可能な現在、可能な限り早急にStruts 6.1.1への更新を適用することが強く推奨されます。アップデート後は新バージョンでアプリケーションの動作確認を行い、問題なく機能することを検証した上で本番環境へ反映するようにしましょう。

アップデート困難な場合のワークアラウンド：緩和策の概要と適用手順を解説する。

しかし、現実にはすぐにアップデートできないケースもあり得ます。レガシーシステムでフレームワークを即座に差し替えられない場合など、開発者はワークアラウンド（緩和策）を講じる必要があります。Apache Strutsの開発チームは、アップデートが困難な利用者向けに今回の脆弱性を軽減するための対処法を提示しています。その概要は、XMLパーサが外部エンティティを読み込まないよう設定を上書きするというものです。具体的には、Strutsの設定でカスタムのSAXParserFactoryを指定する方法、あるいはJVM全体の設定としてXMLパーサの外部アクセス禁止を有効にする方法の2つが推奨されています。これらのワークアラウンドにより、フレームワークのバージョンを上げずとも外部エンティティ解決を無効化でき、脆弱性の悪用を防ぐことが期待できます。ただし、あくまで一時的な回避策であり、根本的には最新バージョンへの移行が望ましい点は留意してください。

xwork.saxParserFactoryプロパティでXML外部エンティティを無効化する方法：カスタムパーサー実装による対策

1つ目のワークアラウンドは、Strutsの設定でxwork.saxParserFactoryプロパティを利用する方法です。Struts 2では、このプロパティにカスタムのSAXParserFactoryクラスを指定することで、フレームワークがXMLをパースする際にそのクラスを使用します。開発者はXML外部エンティティを無効化したSAXParserFactoryを自作または選定し、例えばStrutsの設定ファイル（struts.xml）で次のように指定します。<constant name="xwork.saxParserFactory" value="com.example.SecureSAXParserFactory" />これにより、StrutsはXMLパーサ生成時にcom.example.SecureSAXParserFactoryを用いるようになります。SecureSAXParserFactoryの実装では、内部でXMLReaderやSAXParserを生成する際にXMLConstants.FEATURE_SECURE_PROCESSINGをtrueに設定したり、javax.xml.parsers.SAXParserFactory#setFeatureメソッドでhttp://xml.org/sax/features/external-general-entitiesなどをfalseに設定することで、外部エンティティを読み込まないセキュアなパーサを提供します。この方法は、アプリケーション側でコード変更（カスタムクラスの用意）が必要ですが、アップデートできない場合の有効な緩和策となります。

JVM全体で外部エンティティを無効化する設定：システムプロパティの活用方法と効果を具体例とともに説明する

2つ目のワークアラウンドは、JVMのグローバル設定としてXMLパーサの外部エンティティアクセスを禁止する方法です。具体的には、Java起動時に以下のシステムプロパティを設定します：-Djavax.xml.accessExternalDTD=""、-Djavax.xml.accessExternalSchema=""、-Djavax.xml.accessExternalStylesheet=""。これらの設定値を空文字（””）にすることで、DTDやXMLスキーマ、XSLTの外部参照をすべてブロックする効果があります。これにより、Strutsに限らずアプリケーション内の全てのXML処理で外部エンティティが無効化され、今回のXXE脆弱性を包括的に緩和できます。この方法はJVMレベルの設定変更であり、アプリケーションコードには手を入れずに済む利点があります。ただし、アプリケーションが正当な目的で外部DTDやスキーマを読み込んでいる場合に副作用（機能が動作しなくなる）が出る可能性があるため、事前に影響範囲を確認する必要があります。いずれにせよ、以上のワークアラウンドを施した上でも、恒久対策としては将来的に脆弱性修正済みバージョンへアップデートする計画を立てるべきです。

開発者・運用担当者が直ちに取るべき行動：脆弱性への対応策の実施と適用後の検証ポイントを徹底解説する。

本脆弱性に対処するために、開発者・運用担当者が直ちに行うべき行動は以下の通りです。まず、前述のアップデートまたはワークアラウンドを速やかに適用し、システムを防御すること。適用後は、実際に脆弱性が塞がったかを検証します。既知のXXE攻撃ペイロード（安全な範囲でテスト用に加工したもの）を投入し、外部エンティティが解決されないこと、機密ファイルにアクセスできなくなったことなどを確認してください。また、攻撃の痕跡がないかサーバーのログを遡って調査することも重要です。もし既に不審な外部参照エラーや異常なレスポンスが記録されている場合、情報漏洩等が発生していないか調査を行いましょう。さらに、開発プロセスにおいても教訓を生かす必要があります。今後はライブラリのアップデートを怠らないこと、依存するソフトウェアの脆弱性情報を定期的にモニタリングすること、リリース前にセキュリティレビューやペネトレーションテストを実施することなど、総合的な対策を講じていくことが望まれます。

長期的視点：古いStrutsからの移行計画策定と安全な開発体制の強化 – 技術負債の解消と継続的なセキュリティ向上を徹底解説

最後に、長期的な視点での対策も重要です。現在Struts 2系の古いバージョンを使用している場合、今回の脆弱性を契機に最新プラットフォームへの移行計画を立てるべきでしょう。EOLとなったバージョンを使い続けることは、今後も未修正の脆弱性に晒され続けることを意味します。そのため、時間とコストを確保し、Struts 6系へのアップグレードや、場合によっては別のフレームワークへの移行を検討してください。また、組織としての安全な開発体制の強化も不可欠です。今回のようにオープンソースのコンポーネントで重大な脆弱性が発見された場合に迅速に対応できるよう、日頃から脆弱性情報収集とインシデント対応のプロセスを整備しておきましょう。古いフレームワークの使用は技術的負債（Tech Debt）とも言え、これを解消することが結果的にセキュリティ向上とメンテナンス性向上につながります。開発チームはバージョン管理とアップデート計画を明確にし、定期的なアップグレードを怠らない文化を醸成することが望まれます。以上を踏まえ、今回の脆弱性への対処を一過性の対応で終わらせず、将来的なセキュリティ強化の機会として活用することが大切です。

JVNが公表した Apache Struts 2 XML 検証の欠如の脆弱性に関する注意喚起のポイント

JVNによる脆弱性公表の概要：Apache Struts 2のXML検証欠如が公式に注意喚起された経緯

Japan Vulnerability Notes（JVN）は日本の情報セキュリティ機関（IPAおよびJPCERT/CC）が運営する脆弱性情報ポータルであり、今回のApache Struts 2脆弱性についても公式に注意喚起を行いました。JVNでは2026年1月14日に「Apache Struts 2におけるXML検証の欠如の脆弱性（S2-069）」として本件の詳細が公開されています。JVNによる脆弱性公表の目的は、日本国内の開発者やユーザに対して迅速かつ正確な情報伝達を行うことにあります。Apacheの英語情報だけでは把握漏れが起きる恐れがあるため、JVNが日本語でポイントを整理して周知することで、より広範なユーザ層へ注意喚起を図っています。今回のJVN報告もApacheから提供された情報をベースに、影響範囲や対策方法が簡潔にまとめられており、多くの国内組織がこれを参考に対応を進めました。JVNの公開はメディア報道などにもつながり、Struts利用者への速やかな警鐘として機能しました。

JVNが示す脆弱性の内容：XXE脆弱性の原因（XML検証欠如、CWE-112）と詳細な技術情報について

JVNの脆弱性情報では、本件の技術的な内容が端的に示されています。「XML検証の欠如」というタイトルが示す通り、XML入力に対する妥当性検証の不足が問題の核心であると説明されています。JVNレポートではCWE番号としてCWE-112（Missing XML Validation）が付与され、これはまさにXMLにおける検証抜けを表す分類です。また、CVE-2025-68493という識別子も明記され、Apache StrutsのXWorkコンポーネントでXXEが可能になる旨が記載されています。技術的概要の部分で、XWorkがXMLを解析する際に適切な検証が行われず任意の外部リソース参照が起こり得る、と説明されており、要するにXXE脆弱性であることが誰にでも分かるようになっています。JVNは専門的な内容を平易な表現でまとめる傾向があり、今回も「XML検証不足で外部エンティティを許してしまう」という本質が強調されています。

JVNで挙げられた想定される影響：情報漏えい・DoS・SSRFなど深刻な被害の可能性を解説し注意喚起

JVNの注意喚起では、想定される影響についても明示されています。具体的には、「データ漏えいやサービス運用妨害（DoS）攻撃、サーバーサイドリクエストフォージェリ（SSRF）攻撃等の被害が生じる可能性がある」と記載されました。これは、本書で述べてきた機密情報の漏洩、サービス停止、内部ネットワークへの不正アクセスといったリスクをそのまま要約したものです。JVNがここまで具体的に影響を列挙するのは、本脆弱性の深刻さを強調するためと言えます。単なる情報漏洩に留まらず複数の攻撃に発展し得る点を示すことで、利用者に早急な対応を促す狙いがあります。情報漏えい・DoS・SSRFという三点セットは極めて深刻な被害に繋がるものであり、JVNはこの脆弱性が複合的な脅威をはらむことを明確に示しました。特にSSRF攻撃についても触れられている点は、単なるデータ漏洩事故ではなく外部への攻撃踏み台となる危険性まで含めて警鐘を鳴らしたものと解釈できます。

JVNが公表した影響範囲：脆弱性が及ぶStrutsのバージョン一覧とEOLへの注意喚起情報を示すもの。

JVNでは影響を受けるシステム（バージョン範囲）も明示されました。Apache Struts 6.0.0〜6.1.0、Struts 2.5.0〜2.5.33、およびStruts 2.0.0〜2.3.37が該当すると列挙され、さらに注釈として「2.0.0〜2.3.37および2.5.0〜2.5.33は既にEOLとなっています」と記載されています。これは、サポートが切れた古いバージョンにも本脆弱性が存在するが、修正アップデートが提供されないことを示唆しています。JVNがこうしたEOLに関する注意を添えるのは、利用者に対し「古いバージョンを使い続ける危険性」を認識させるためです。実際、EOL製品上の脆弱性は組織にとって大きなリスクであり、今回JVNが敢えてそれを強調したことで、開発者にアップグレードの必要性を再認識させる効果がありました。このように、影響範囲として単なるバージョン一覧に留まらず、サポート切れ状況まで含めて伝える点にJVNの配慮が見られます。

JVNによる対応方法の提示：最新版アップデートおよびワークアラウンド適用の推奨事項の詳細を解説する。

JVNレポートでは対策方法についても簡潔に触れられており、開発者に向けてアップデートとワークアラウンドの双方が提示されました。具体的には「最新版へアップデートしてください。本脆弱性はApache Struts 6.1.1で修正されています」と明記され、加えて「アップデート適用できない場合の回避策が示されている」として、開発者提供情報（Apache公式のアドバイザリ）を参照するよう案内しています。つまりJVNとしては、原則は6.1.1へのバージョンアップで根本解決し、それが難しければ一時的に開発元推奨のワークアラウンドを実施するよう促しているわけです。この推奨内容は非常に合理的で、Struts利用者にとって取るべき行動が明確になります。JVNは対策の重要性を強調するため「開発者が提供する情報をもとに最新版へアップデートして下さい」と呼びかけており、また「アップデートできない場合は回避策を」と丁寧に補足しています。これにより、様々な事情でアップデート遅延が起こりがちな現場にも現実的な対応策が示された形です。

開発者・利用者へのJVNからのメッセージ：早急な対策実施の呼びかけと注意点を伝達する重要性について解説

全体を通して、JVNから開発者・利用者へのメッセージは明確です。それは「脆弱性を軽視せず、早急に対応措置を取ってほしい」という点に尽きます。JVNの文面は客観的な情報提供に徹していますが、その中で重要度（本件ではApache基準でImportant）や想定被害の深刻さが示されており、利用者に危機感を持たせるよう工夫されています。また、開発元からの情報参照を促しつつ、日本語で要点をかみ砕いているため、現場のエンジニアにとって非常に有用です。JVNの注意喚起を受け取った多くの組織は、内部で緊急対策会議を開き、対応方針を決定したことでしょう。「最新版へのアップデート」「回避策の適用」「システム影響調査」といった具体的なアクションがJVNを通じて提示されたことで、利用者は何をすべきか迷わず動けたはずです。結果として、JVNからの呼びかけは本脆弱性への素早い対処を促進し、日本国内の被害拡大防止に寄与しました。このケースは、公的な脆弱性情報共有機関からの注意喚起の重要性を改めて示すものと言えるでしょう。