両 CVE の修正版は 3.1 系にのみ存在します。 そのため 3.0.x ユーザーには「バージョン番号を変えるだけ」という選択肢はなく、 大規模バージョン系統間の移行が必要です —— そして 3.1 は公式に破壊的変更と明記されています(公式 ChangeLog.txt の 3.1.0.M1 節より抜粋):

テンプレートで ${#request.…} / ${#session.…} を書いたことがある場合、アップグレードすると直接エラーになります。これらの値は Controller が Model に入れるように変更する必要があります。 これは計画が必要な移行であり、バージョン番号を変えるだけではありません。

この系統に該当するのは誰か

deps.dev の依存数(2026-09-04 直接取得、誰でも再計算可能):

最も導入が多い単一バージョンは 3.0.11.RELEASE で、3.1 系で最も多い 3.1.3 より 36% 多く、しかも同系統内に出口がありません。

使い方

終了コード:2 = 同系統内に修正版がないバージョンのアーティファクトを検出 · 1 = 影響ありだが同系統内でアップグレード可能 / 判定不能 · 0 = 検出なし · 3 = 使い方またはパスのエラー。 CI に直接組み込めます。

何をスキャンするのが最も正確か

ビルド成果物(target/*.jar、*.war)をスキャンし、ソースディレクトリはスキャンしないでください。 Thymeleaf はほとんどの場合 spring-boot-starter-thymeleaf によって推移的に導入されますが、starter 自体はバージョンを持ちません —— pom には Thymeleaf のバージョン番号が一切見えません。この場合、ツールは「pom からは判定できない」と明示し、存在しないものとしては扱いません。

信頼性の高い順に3つの識別根拠:

1. MANIFEST の Implementation-Version —— jar がリパッケージツールでリネームされても認識可能。 (Thymeleaf 公式 jar の META-INF/ には MANIFEST.MF のみで maven/ ディレクトリは存在しないため、これが最も確実な根拠です。)
2. Maven メタデータ pom.properties
3. jar ファイル名

fat jar / war 内の BOOT-INF/lib/、WEB-INF/lib/ は分解して個別に確認し、内包 jar の MANIFEST も読み取ります。

2件の CVE は異なる2つのメカニズム

2件目の影響範囲には 3.1.4 が含まれるため、1件目の advisory に従って 3.1.4 にアップグレードした人は、2件目の影響範囲に入ります。

ただし、これを「公式が修正しきれていない」と読まないでください —— 2件の advisory は異なるメカニズムを説明しており、 3.1.4(2026-04-12)と 3.1.5(2026-04-21)の公式リリースは9日間隔てており、 前の修正が不完全だったとする公式の記述は一切ありません。本ツールは事実を並べて提示するだけで、その結論を代わりに下すことはしません。

判定表の由来と、それが正しいかの検証方法

RuleTable.java の各数値はすべて遡って検証可能です:

これは2つの一次ソースと判定表を照合します —— OSV の影響範囲とバージョン別リスト、Maven Central の maven-metadata.xml —— 一致しない場合は非ゼロで終了します。

3つの取り決め:

• データ取得失敗時は終了コード 2 で、「検証できなかった」と報告し、「検証通過」とは報告しない。ネットワーク障害時に全て正しいと読んではいけない。
• 照合のみ行い、コードは自動変更しない。数値が変わった場合は人がどのように変わったかを確認する。
• このツールを陳腐化させる2つの事象を特に監視する:3.1.6 がリリースされたか、3.0 系に突然 3.0.16 が登場したか。

ビルド

実行時の依存関係ゼロは意図的です:調査ツールはどんな環境にも放り込んですぐ実行できる必要があります。

License

Apache-2.0