今回の対策は、Strutsの更新に加え、any-setter用の設定を有効にし、必要な受け口を明示する作業を含みます。新しい設定の初期値は互換性のためfalseです。稼働バージョンだけで対応完了とせず、実効設定とアプリの動作まで確認してください。
2026年10月29日12時、JVNの新着一覧にJVN#82782759が掲載されました。対象はApache Struts 2のRESTプラグインです。外から受け取ったJSONやXMLの値をJavaオブジェクトに入れる際、一部の受け口で、本来意図した入力の認可チェックが行われない問題が公表されています。
本稿の確認時点は10月29日16時台（日本時間）です。確認したJVNとApacheの資料に、本件のCVE番号、CVSS値、実悪用や被害件数の記載はありません。未確認の項目を「危険度が低い」「被害はない」とは解釈しません。公開された対象条件に合うサービスは、開発・保守担当が優先して点検してください。
今日公表されたことと、修正版が出た日を分ける
| 日付 | 公式に確認できること | 意味 |
|---|---|---|
| 2026年8月31日 | Apacheの課題WW-5712が作成 | 開発元の課題記録。表示時刻のタイムゾーンは本稿では確定しない |
| 2026年10月2日 | Struts 7.4.0の一般提供を発表 | 対応機能を含む版はすでに配布されている |
| 2026年10月29日 | JVNが本件を公表 | 国内向けに対象条件と対処が整理された今回の更新 |
課題の修正対象版はWW-5712、7.4.0の提供日はApacheの公式発表で確認できます。本日のJVN公表は、修正版が今日初めて出たという意味ではありません。 また、同じ7.4.0で対処される別のStruts脆弱性のCVEや評価値を、本件へ転用しないでください。
何が起こるのか：通常の項目と「それ以外の項目」の受け口
StrutsはJavaでWebアプリを作るためのフレームワークです。RESTプラグインは、リクエスト本文のJSONやXMLを読み取り、アクションやモデルと呼ばれるJavaのオブジェクトへ値を渡します。この変換をデシリアライズ、オブジェクトの項目へ値を結び付ける処理をバインドと呼びます。
@StrutsParameter は、外部入力を受け取ってよい項目を明示する印です。一方、Jacksonの @JsonAnySetter は、通常の項目名に当てはまらないキーを引き受ける受け口です。今回、通常の項目にかかるチェックが、この「それ以外」の経路を包んでいませんでした。Apacheの課題説明
たとえば、顧客管理システムが追加情報を柔軟に受け取れる設計だとします。追加キーを集める受け口に、入力対象にするつもりのなかった業務上の値まで入ると、その後の保存処理によってはデータの整合性を損なうおそれがあります。これは仕組みを説明する架空例であり、実際の被害企業や本件で確認された攻撃ではありません。
JVNが示す想定影響はデータの改ざんにつながる可能性です。「この問題だけでOSコマンドを実行できる」「すべてのStrutsアプリで無認証攻撃が成立する」とは書かれていません。攻撃者がどの入力へ届くか、値が後段でどう使われるかはアプリ側の条件も調べます。JVNの想定影響
誰が対象か：版・プラグイン・設定・コードを組み合わせて判定
| 確認する条件 | 確認内容 |
|---|---|
| Strutsの版 | JVNの対象は7.2.1～7.3.0 |
| 入力経路 | RESTプラグインで、リクエスト本文からアクションまたはモデルへバインドしている |
| 既存の認可設定 | struts.parameters.requireAnnotations=true が有効 |
| 動的な受け口 | 対象のクラスに@JsonAnySetterを宣言している |
上の条件はJVN本文に基づきます。古い版や別のプラグインをこの表だけで「安全」と保証するものではありません。また、struts.parameters.requireAnnotations をfalseに変えて条件から外すのは防御策ではありません。既存の入力制限まで弱めてしまいます。
棚卸しでは、設計資料のバージョンだけでなく、実際に配備したWARや依存関係の記録を確認します。coreとRESTプラグイン、複数サービス、待機系の版がそろっているかを点検してください。コード検索でアノテーションが見つからなくても、依存ライブラリや継承先まで確認できていなければ「未確認」です。
対策の対応表：版だけでなく設定と受け口まで確認する
| 状態 | 対応・判断 |
|---|---|
| 7.2.1～7.3.0で対象条件に該当 | 7.4.0以降の適切な修正版へ更新し、追加設定と受け口を点検 |
| 7.4.0以降だがany-setter用設定がfalseまたは不明 | 追加チェックの有効化と実効設定を確認。版だけで完了にしない |
| 追加設定がtrue、必要なメソッドまたはフィールドに明示的な許可がある | 入力の許可範囲、入れ子の深さ、業務上の値の検証、回帰テストを確認 |
| 版・コード・設定の資料が不足 | 保守担当へ証拠を依頼し、未確認として残す |
Apacheの公式仕様では、7.4.0から struts.rest.anySetter.requireAnnotations=true を指定できます。ただし、この制御は struts.parameters.requireAnnotations が有効であることも前提です。新設定は初期値falseのため、アップデートだけで既存の動作を変えない設計になっています。
<constant name="struts.parameters.requireAnnotations" value="true"/><constant name="struts.rest.anySetter.requireAnnotations" value="true"/>必要なany-setterのメソッドまたはフィールドには @StrutsParameter(allowDynamicKeys = true) を付けます。単なる @StrutsParameter だけとは区別されます。不要な受け口は残さず、付ける前に「任意のキーを受け入れる必要があるか」を確認してください。設定とアノテーションの仕様
この許可は、「この受け口が動的キーを受け取ってよい」という意思表示です。各キーの業務上の正当性や、利用者がそのデータを変更してよいかを、すべて判定してくれるものではありません。許可した受け口でも、キーの種類・値の型・長さ・範囲・業務権限など、用途に必要な検証を別に設計します。
公式仕様では、depth=0 は動的キーの値としてスカラーを受け取り、depth=1 は1段のオブジェクトや配列も許容します。深さを増やすほど安全になるわけではありません。また、@JsonCreator のパラメータにあるany-setterは、追加チェック有効時にキーを拒否します。フィールドやメソッドと同じ移行方法だと思い込まないでください。詳細仕様
更新後の確認：正常な入力と、拒否したい入力の両方を試す
次の表は、管理権限のある検証環境で行う回帰テストの計画です。顧客の実データや公開中の第三者サービスでは試しません。本稿でStrutsの実アプリを起動して得た結果ではなく、確認すべき期待結果を整理した教材です。
| 検証項目 | 確認する期待結果 |
|---|---|
| 必要な通常項目 | 従来の正当な登録・更新が壊れていない |
| 明示許可したany-setterへの業務上必要なキー | 設定した深さとアプリの検証条件の範囲で処理される |
| 明示許可していないany-setterへのキー | オブジェクトの対象受け口へ値が設定されない |
| 許可した深さを超える値 | 受け口へ値が設定されない。必要な既存機能に影響しないかも確認 |
| JSONとXMLの両方を扱うサービス | 利用している両経路で入力・保存結果を確認 |
| 再配備・複数ノード | 実際の版と実効設定が全台で一致する |
Apacheは、許可がないキーや深さを超えた値を落とし、拒否理由に応じたWARNを記録する仕様を説明しています。HTTPの応答コードだけで合否を決めず、受け口の値や保存結果を確認してください。常にリクエスト全体がエラーになるとは限りません。拒否時の仕様
- 1対象サービスと担当者を一覧にする。版・REST利用・アノテーション・実効設定の証拠を残す。
- 2検証環境で版を更新し、必要なany-setterと設定を見直す。業務上不要な動的入力を閉じる。
- 3上の正常系・拒否系を、使っている入力形式と保存処理まで通して確認する。テスト値と期待結果は機密を含まないものにする。
- 4保守時間、復旧方法、障害時の連絡先を決めて配備する。設定の反映と全台の版を確認する。
- 5エラーや警告の増加、正規利用者の入力欠落、保存データの不整合を点検し、日時・担当・証拠を記録する。
すぐ更新できない場合と、過去のデータの点検
JVNは、リクエストから値が入るActionやModelで @JsonAnySetter を使わない方法、必要なら格納前にアプリ側で検証する方法を回避策として挙げています。JVNの回避策 受け入れられるキーと値を決め、機能が変わる範囲を検証します。「危なそうな文字を少し除く」だけで完了とはしません。
WAFやアクセス制限を追加しても、アプリが意図した項目だけを受け入れる設計の確認は残ります。暫定策には責任者と更新期限を付けてください。一般利用者がJavaやサーバーの設定を変更する必要はなく、サービスの保守担当へ対象確認を依頼するのが出発点です。
過去に対象構成で運用していた場合は、変更履歴や監査記録、説明できない追加項目や値がないかを点検することも検討します。これは編集上の運用提案で、本件の侵害が確認されたという意味ではありません。更新できたことと過去に改ざんされていないことは別です。記録が不足する期間は未確認として残します。
LLMには、入力経路の棚卸しとテスト計画を手伝わせる
設定ファイル全体や業務データをそのまま渡さず、サービス名を仮名化し、必要な版・設定・短いコード抜粋と公式資料を渡します。コード中の秘密情報、接続先、認証情報は取り除きます。LLMには実機変更や攻撃再現を頼まず、判断の根拠と未確認事項を並べてもらいます。
Apache Struts 2 RESTのJVN#82782759について、防御点検を読み取り専用で補助してください。公式資料:https://jvn.jp/jp/JVN82782759/index.htmlhttps://struts.apache.org/core-developers/struts-parameter-annotationhttps://issues.apache.org/jira/browse/WW-5712
入力: サービス仮名 / 配備済みStruts core・RESTプラグインの版 / REST本文のJSON・XML利用 / struts.parameters.requireAnnotationsの実効値 / struts.rest.anySetter.requireAnnotationsの実効値 / 秘密を除いた@JsonAnySetterの宣言箇所 / 更新・テスト記録
1. 7.2.1～7.3.0というJVNの対象版、REST利用、設定、受け口を組み合わせて対象候補・要追加確認を整理する。2. 7.4.0以降でも新設定の初期値falseを考慮し、版だけで対応済みにしない。3. 必要なメソッド・フィールドのallowDynamicKeys、depth、creatorパラメータ形式の扱いを公式仕様に照合する。4. 動的入力の許可と業務上のキー・値の検証、利用者の権限確認を分ける。5. 正常入力、未許可の受け口、深さ超過、利用中のJSON/XML経路のテスト計画を作る。HTTPステータスだけでなく格納値・保存結果を確認対象にする。6. 稼働版・実効設定・全台反映・担当者・完了証拠・残る未確認を表にする。7. 根拠のないCVE番号、CVSS、実悪用の有無を作らない。検索で見つからないことを非該当や侵害なしの証拠にしない。
実機接続、外部探索、攻撃再現、依存パッケージ変更、設定変更、配備はしないでください。機密情報の追加提出も求めないでください。出力: サービス / 確認済み事実 / 根拠URLと確認日 / 未確認事項 / 対応案 / テストの期待結果 / 担当 / 完了証拠点検プロンプトと空の記録表をダウンロードできます。脆弱性情報の読み方は連載の導入記事、Web基盤の複数層を分けて確認する考え方はLinuxとPHPの攻撃連鎖の記事でも扱っています。