脆弱性・インシデント

S2-069(CVE-2025-68493)とは|Apache Struts 2のXXE脆弱性の影響範囲・判定手順と対策

S2-069(CVE-2025-68493)とは|Apache Struts 2のXXE脆弱性の影響範囲・判定手順と対策

S2-069(CVE-2025-68493)は、Apache Struts 2の土台であるXWorkが設定ファイルのXMLを読むときに、外部エンティティを解決してしまう脆弱性です。2026年1月11日に公表され、影響はStruts 2.0.0〜2.3.37、2.5.0〜2.5.33、6.0.0〜6.1.0、修正は2022年リリースの6.1.1に入っています。スキャナで検出されて調べている人に向けて、攻撃が成り立つ前提、公開PoCとEPSSの読み方、2026年11月10日時点の更新先、更新できない場合の回避策を、公式告知とソースコード、手元での実測をもとに整理します。

まとめ:S2-069の要点と2026年11月時点で取るべき対応

  • 対象はstruts.xmlや入力検証の定義ファイルといった設定XMLです。HTTPリクエストで送られるXMLを解析する処理ではありません。
  • CVSS 3.1はNVDで8.1(利用者の関与が必要=UI:R)です。CISAのKEVには2026年11月9日版でも載っていません。
  • 公開PoCとNucleiの公式テンプレートが狙う/struts2-xml-parser/xmlParserNoDtdParseは、Strutsの標準機能ではなく検証用アプリの独自パスです。EPSSは50.4%と高く出ていますが、自社アプリが同じ作りでなければ当てはまりません。
  • いま上げるなら7.4.0か6.12.0です。6.1.1でS2-069は塞がりますが、2026年8月と10月の告知(S2-070〜S2-078)が6系・7系にも影響します。
  • 2.3系・2.5系はサポートが終わっており修正は出ません。JVMのシステムプロパティで外部参照を止め、6系以降かほかのフレームワークへの移行を計画します。

S2-069(CVE-2025-68493)の公表内容と深刻度の評価

Apache Strutsの公式告知S2-069は、影響を「データの漏えい、サービス拒否、サーバーサイドリクエストフォージェリ」、最大の深刻度を「Important」としています。報告者はAIによる脆弱性解析を手がけるZAST.AIです。

6.1.1のリリースから告知・続報までの時系列

修正版の公開と告知が3年以上離れているのが、この脆弱性の特徴です。

日付 発表主体 内容
2022-11-28 Apache Struts 6.1.1をリリース
2026-01-11 Apache Struts S2-069とCVEを公表
2026-01-14 JVN JVNVU#91185180を公開
2026-07-29 ProjectDiscovery Nucleiテンプレートを追加
2026-08-14 Apache Struts S2-070〜074を公表
2026-10-02 Apache Struts 7.4.0・6.12.0をリリース
2026-10-05 Apache Struts S2-075〜078を公表
2026-10-29 JVN JVN#82782759を公開

日付はStruts公式の2026年の告知一覧とリリース一覧、JVNVU#91185180で確かめた値です。11月10日に告知一覧を見直した時点で、S2-079以降の告知は出ていません。

評価主体ごとに異なるCVSSの数値とUI:Rの意味

深刻度の数値は、どの組織が付けたかで変わります。各指標の読み方はCVSSv3のスコアの目安と計算式の解説にまとめています。

評価主体 評価 ベクトルの要点
Apache(CNA) Important 数値なし
NVD・CISA-ADP 8.1 UI:R・C:H・A:H
Red Hat 7.1 A:Lと評価

NVDの登録内容とGitHubのアドバイザリ(GHSA-qcfc-hmrc-59×7)はどちらも8.1で、9.8のような値は一部のセキュリティ企業が独自に付けたものです。注目点はUI:R(利用者の関与が必要)で、攻撃者がリクエストを送るだけでは成立しないことを示します。弱点の分類は、ApacheのCVEレコードがCWE-611(XML外部実体参照の不適切な制限)、JVNがCWE-112(XML検証の欠如)です。

XWorkの設定XML解析で外部エンティティが解決される仕組み

告知の問題欄は「XWorkコンポーネントのXML設定の解析が、XMLを適切に検証していない」です。読むべき言葉は「設定」です。

DomHelperが読む設定XMLと6.1.1で入った修正

struts.xmlとそこからincludeされるファイル、プラグインjar内のstruts-plugin.xmlはXmlConfigurationProviderが、入力検証の定義(*-validation.xml)はDefaultValidatorFileParserが読み込み、どちらも内部でDomHelper.parseを呼びます。StrutsのソースコードでDomHelperを呼んでいるのは、この設定と検証定義の読み込みだけです。

6.1.1のDomHelper.javaは、SAXパーサーを作った直後にexternal-general-entitiesとexternal-parameter-entitiesをfalseにし、設定できなければ例外で止めます。2.5.33のDomHelperにはこの処理がありません。2026年11月10日に、Maven Centralから取得した両版のjarでDomHelperに外部エンティティ入りのXMLを渡したところ、2.5.33は参照先ファイルの中身を展開し、6.1.1は展開しませんでした(JDK 21.0.13・各3回で同じ結果)。

HTTPリクエストのXMLとは別問題である理由と被害の範囲

攻撃が成り立つのは、攻撃者が用意したXMLをStrutsが設定として読む場面です。利用者がアップロードしたファイルを検証定義として読む独自実装、複数のチームが書き込める共有ディレクトリの設定をincludeする構成、出どころを確かめていないプラグインjarの組み込みが当たります。CI/CDでWARに固めた設定だけを読む通常の構成では、外部の人が設定XMLを差し替える経路が無く、前提を満たしません。

前提を満たした場合は、file:でサーバー内のファイルを読む、http:で内部ネットワークへリクエストを送る(SSRFの仕組みとクラウドメタデータの悪用経路)、入れ子のエンティティでメモリを消費させる、といった被害がありえます。設定の解析は主に起動時と再読み込み時なので、読んだ内容が攻撃者に戻るかどうかは、エラーメッセージやログの出し方しだいです。RESTプラグインがHTTPの本文を扱う処理は別の仕組みで、こちらには2017年のS2-052(CVE-2017-9805)があり、KEVにも載っています。

公開PoC・Nucleiテンプレート・EPSSの読み方

S2-069を調べ始めるきっかけは、多くの場合スキャナの検出です。検出の根拠が何かで、取るべき対応が変わります。

公開PoCとNucleiテンプレートが狙う独自エンドポイント

2026年2月4日にGitHubへ公開されたPoCと、ProjectDiscoveryが7月29日に追加したNucleiの公式テンプレートは、どちらも/struts2-xml-parser/xmlParserNoDtdParseへ外部エンティティ入りのXMLをPOSTします。テンプレートは、応答に「Struts」という語があるかを見たあと、このパスへ外部のコールバック先を参照するXMLを送り、DNSかHTTPの問い合わせが届けば検出とします。

このパスはStrutsの標準機能ではありません。Strutsのソースコードには見当たらず、リクエストの本文をそのままXMLとして解析する検証用アプリを前提にしています。自社のアプリにこのパスが無ければ、テンプレートは404で終わり、検出されません。逆に検出された場合は、Strutsの版に関係なく、そのアプリが受け取ったXMLを外部エンティティ付きで解析しているという、より直接の問題を示します。

Nessusなど版番号だけで判定するスキャナで検出されたとき

Nessusのプラグイン290256は、この問題を実際には試さず、アプリが示す版番号だけで判定すると明記しています。版が影響範囲に入っていれば検出されるので、検出は「版を上げる必要がある」という知らせとして受け取り、緊急度は次の章の棚卸しで決めます。同じプラグインは「Exploit Available」を真としていますが、公開ページには根拠となるPoCの特定や、その実行条件の説明はありません。

EPSSの予測確率とKEV掲載状況の違い

EPSSは、CVEが今後30日以内に実環境で悪用される確率を推定する指標です。FIRSTのAPIで日付を指定して取得すると、2026年11月9日の値は0.504、パーセンタイルは0.989(全CVE中の上位1.1%)でした。一方でCISAのKEVは、11月9日版でもCVE-2025-68493を載せていません。KEVは悪用が確認された脆弱性の一覧で、EPSSは予測なので、両者は別の物差しです。EPSSのFAQは、値が変わるのは攻撃コードの公開や検知シグネチャの公開といった新しい信号が届いたときだと説明していますが、このCVEの値がどの信号で上がったかは公表されていません。EPSSの値だけでは、自社のStrutsアプリで攻撃が成り立つかは分かりません。判断は、設定XMLを差し替えられる経路と、リクエストのXMLを自前で解析している処理の有無で行います。

影響を受けるStrutsのバージョンと2026年11月時点の更新先

S2-069の影響範囲は、公式告知とJVNで一致しています。更新先の列は、後から公表された告知まで含めて選ぶべき版です。

系統 S2-069の影響 サポート 更新先
2.0〜2.3系 2.0.0〜2.3.37 2019-09-12終了 修正なし
2.5系 2.5.0〜2.5.33 2024年4月ごろ終了 修正なし
6系 6.0.0〜6.1.0 継続 6.12.0
7系 影響なし 継続 7.4.0

2.5系の終了はStruts公式のEOL一覧に2023-10-30と載っていますが、これは「6か月後に終了する」と予告した日です。更新先はMaven Centralのstruts2-coreで11月10日に確かめた最新版で、7.4.0と6.12.0はどちらも2026年10月2日のリリースです。GitHubのリリース一覧には11月8日付で7.5.0と6.13.0がプレリリース(正式公開前の版)として出ていますが、Maven Centralのstruts2-coreでは11月10日時点も最新が7.4.0のままで、対応する告知もありません。正式に公開されたら、更新先が1段上がるかを告知一覧で確かめてください。2.3系以前で別配布だったorg.apache.struts.xwork:xwork-coreとcom.opensymphony:xworkも対象に入ります。

S2-070〜S2-078の告知で更新先が7.4.0・6.12.0になった経緯

8月14日のS2-070〜074はJSONプラグインやCSP違反レポートの受け口などの問題で、7.3.0と6.11.0で直りました。10月5日のS2-075〜078(CVE-2026-104711〜104714)は7.3.0と6.11.0も影響版に含むため、更新先が1段上がっています。

告知 内容 深刻度 条件
S2-075 OGNL注入でRCEのおそれ Moderate 旧RESTfulマッパー使用
S2-076 応答の肥大化でDoS Moderate BigDecimalをタグで出力
S2-077 本文を上限なく読みDoS Important RESTプラグイン使用
S2-078 他者の日時が応答に混入 Moderate 日時を整形する文言

優先度が高いのはS2-075です。struts.mapper.classに旧来のrestfulマッパーを指定したアプリで、細工したリクエストからOGNL式を注入できます。影響は2.0.0〜2.3.37、2.5.0〜2.5.33、6.0.0〜6.11.0で、7系はOGNLの許可リスト(struts.allowlist.enable)を無効にした場合だけ7.0.0〜7.3.0が対象です。既定のマッパー、restful2、RESTプラグインは対象外と告知に書かれています。S2-069より、この条件に当たる2.x系・6系のアプリを先に片付けます。

7系RESTプラグインの@JsonAnySetterに認可が掛からない問題

10月29日公開のJVN#82782759は、Struts 7.2.1〜7.3.0のRESTプラグインで、@JsonAnySetterで受けた値に@StrutsParameterの認可が掛からない問題で、S2-069とは別物です。11月10日時点でもCVE番号とCVSSは記載されていません。StrutsParameter注釈の公式説明によれば、7.4.0で追加されたstruts.rest.anySetter.requireAnnotationsは既定がfalseで、7.4.0へ上げただけでは塞がりません。この設定はstruts.parameters.requireAnnotations(7.4.0の既定はtrue)が有効なときだけ効くので、両方がtrueになっているかをstruts.xmlで確かめ、受け取りを許すany-setterにだけ@StrutsParameter(allowDynamicKeys = true)を付けます。

自社のStrutsアプリがS2-069の対象かを判定する手順

判定は「使っているStrutsの版」と「外部の人が設定XMLを差し替えられる経路の有無」の2点で行います。

struts2-coreの版と続報の適用条件の確認コマンド

# 依存関係から版を確かめる(Maven・Gradle)
mvn dependency:tree -Dincludes=org.apache.struts:struts2-core
gradle dependencyInsight --dependency struts2-core --configuration runtimeClasspath

# 配備済みのWARから版を確かめる
unzip -l app.war | grep -E "WEB-INF/lib/(struts2-core|struts2-rest-plugin|xwork)"

# 続報の条件:旧RESTfulマッパー・許可リスト無効・any-setter・動的メソッド呼び出し
grep -rnE 'struts\.mapper\.(class|composite)|struts\.allowlist\.enable|struts\.enable\.DynamicMethodInvocation' --include='*.xml' --include='*.properties' src/
grep -rn '@JsonAnySetter' --include='*.java' src/

jar名の版が6.1.0以下ならS2-069の対象、7.3.0以下か6.11.0以下ならS2-075〜078の影響版です。2.3系以前はxwork-coreが別jarなので両方を探します。restfulという値が出たらS2-075の条件に当たり、restful2だけなら対象外です。アプリが多い組織では、版の洗い出しをSCA(ソフトウェア構成分析)で続ける仕組みに移すと、次の告知時に、依存ライブラリの版を1本ずつ調べる手間を減らせます。

設定XMLを外部から差し替えられる経路の棚卸し

版が対象でも、急ぐかどうかは設定XMLの出どころで決まります。

  1. struts.xmlのincludeが、WARの外のパスや共有ディレクトリを指していないか。
  2. アップロードされたファイルや外部から取得したファイルを、設定や検証定義として読む独自コードが無いか。
  3. 出どころを確かめていないプラグインjarや、利用者ごとに差し替えるjarを組み込んでいないか。
  4. アクションの中で、リクエストの本文をDomHelperや既定設定のSAXParserFactoryに渡していないか(公開PoCが狙う作り)。

4つとも当たらなければ、S2-069単独の緊急度は高くありません。4番目に当たる場合はパーサーの実効設定を確認し、外部エンティティを解決できる実装を直ちに修正します。Strutsを載せているTomcat側の修正版はApache Tomcatの脆弱性一覧で、Javaの基盤全体の追い方はJava脆弱性の一覧と対策で確認できます。

Strutsをすぐ更新できない場合の回避策と効き目の確かめ方

告知は、すぐに更新できない利用者向けに2つの回避策を示しています。どちらもStrutsの設定ファイルではなく、Javaの起動オプションで指定します。

JVMのシステムプロパティで外部参照を止める方法と実測結果

告知どおり、次の3つを空文字で指定します。Tomcatならsetenv.shのCATALINA_OPTSに足します。

CATALINA_OPTS="$CATALINA_OPTS -Djavax.xml.accessExternalDTD= -Djavax.xml.accessExternalSchema= -Djavax.xml.accessExternalStylesheet="

2026年11月10日に、2.5.33のDomHelperで外部エンティティ入りのXMLを解析する小さなプログラムを、この3つを付けて動かすと、ファイルの展開は次の例外で止まりました(JDK 21.0.13・3回とも同じ)。

XWorkException: External Entity: Failed to read external document 'secret.txt', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.

この設定はJAXPの既定値として効き、ファクトリやプロセッサのAPIで明示的に許可した処理には及びません。逆に、APIで許可していない処理が外部のDTDやXMLスキーマ、XSLTを正当に読んでいれば、それも失敗します。本番へ入れる前に、ステージングで起動・入力検証・帳票やXML連携が通るかを確かめてください。

xwork.saxParserFactoryの指定先とstruts.xmlに書けない理由

2つめは、外部エンティティを無効にした独自のSAXParserFactoryを使わせる方法です。DomHelperはこの値をSystem.getProperty("xwork.saxParserFactory")で読むため、-Dxwork.saxParserFactory=com.example.SecureSaxParserFactoryのようにJVMのシステムプロパティで指定します。struts.xmlのconstantに書いても読まれません。struts.xml自体がDomHelperで解析されるファイルだからです。クラスの読み込みに失敗するとDomHelperは既定のパーサーに戻り、2.5系以前ではそのまま無防備に動き続けるため、特別な理由が無ければ1つめを選びます。

続報のS2-075は既定のマッパーかrestful2への切り替え、S2-077はロードバランサーやWAFでの本文サイズの上限が、更新までのつなぎになります。どちらもアプリやURLの改修を伴うので、6系・7系なら回避策を作り込むより6.12.0か7.4.0へ上げるほうが手数は少なく済みます。

2.3系・2.5系のStrutsアプリの更新と移行の判断

回避策は時間を稼ぐ手段で、終点ではありません。2026年の告知だけでも、S2-069、S2-075、S2-077、S2-078が2.x系を影響範囲に含み、どれも修正は出ません。2.3系では、CISAが10月8日に10年前のS2-032(CVE-2016-3081)をKEVへ追加しており、動的メソッド呼び出しを有効にした2.3.20〜2.3.28のアプリは、修正済みの2.3.20.3と2.3.24.3を除き、任意のコード実行のおそれがあります。2.3系のまま動くStrutsアプリが今も探されている、ということです。KEVの期限を自社の更新計画へ写す方法はBOD 26-04の解説で整理しています。

判断の分かれ目は、そのアプリに今後も機能追加があるかです。続くなら、2.5系から6系へ上げるにしても全画面の回帰テストが要るので、Spring MVCなどへの移行と比べて決めます。系統ごとの違いと移行の進め方はStrutsとSpringの違いと移行手順、7系やSpring Boot 3への移行で避けられないjavaxからjakartaへの書き換えはjavaxからjakartaへの移行手順にまとめています。数年内に廃止するアプリでも、残存期間、外部公開の有無、残る脆弱性と回避策の有効性を基に、大規模移行の要否を決めます。JVMプロパティ、旧RESTfulマッパーと動的メソッド呼び出しの無効化、設定を外から差し替えられない運用の固定で、廃止まで持たせる判断もありえます。

社内で版と設定の棚卸しを回せる人が足りない場合は、脆弱性診断・セキュリティ診断で依存ライブラリと設定の出どころを洗い出してから、更新と移行の順番を決める方法もあります。

S2-069(CVE-2025-68493)についてよくある質問

Struts 6.1.1以降を使っていれば、S2-069への対応は不要ですか?

S2-069については不要です。6.1.1のDomHelperには外部エンティティを止める設定が入っています。ただしS2-072〜S2-078は6系にも影響し、すべてを塞ぐのは6.12.0です。6.1.1〜6.11.0なら6.12.0へ上げてください。

Struts 7系はS2-069の影響を受けますか?

受けません。S2-069の影響範囲は6.1.0までで、7.0.0は2024年12月19日のリリースです。ただし7.3.0以下はS2-076〜S2-078の影響版で、7.2.1〜7.3.0はJVN#82782759の対象です。7.4.0へ上げ、RESTプラグインでany-setterを使うならstruts.rest.anySetter.requireAnnotationsをtrueにします。

S2-069はすでに攻撃に悪用されていますか?

2026年11月10日時点で、悪用を確認したという公式の発表はありません。KEVの11月9日版にも載っていません。公開PoCはありますが、Strutsの標準機能ではない検証用エンドポイントを狙うもので、EPSSの値が高くても、自社環境で攻撃が成り立つかは、設定XMLの出どころとリクエストのXMLを解析する処理の有無で判断します。

Struts 2.5系に公式の修正版は出ますか?

出ません。2.5系はサポートが終わっており、Struts公式は終了した系統にセキュリティ修正を出さないとしています。S2-075〜S2-078の告知でも、2.5系は「EOL」と付記されたうえで影響範囲に入っています。JVMプロパティで外部参照を止め、6系以降への更新か移行を計画してください。

脆弱性スキャナでCVE-2025-68493が検出されたら、まず何をすべきですか?

検出の根拠を確かめます。Nessusのように版番号だけで判定するスキャナなら、版の更新計画を立て、設定XMLの出どころを棚卸しします。Nucleiのように実際にXMLを送るスキャナで当たったなら、そのパスでリクエストのXMLを外部エンティティ付きで解析しているので、版に関係なくその処理を直します。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事は以下の記事からリンクされています

資料請求

RELATED POSTS 関連記事

目次