Das heißt, die gesamte 3.0-Linie ist betroffen, und in der versionsweisen Auflistung sind 3.0.15.RELEASE bis 1.0.0 alle aufgeführt. Auf Maven Central endet die 3.0-Linie jedoch bei 3.0.15.RELEASE, danach gab es keine Veröffentlichung mehr:

Die Fix-Versionen beider CVEs liegen auf der 3.1-Linie. 3.0.x-Nutzer haben also nicht die Option „nur die Versionsnummer ändern", sondern nur eine Migration über die Hauptversionslinie hinweg —— und 3.1 ist eine offiziell dokumentierte Breaking Change (wörtlich aus dem Abschnitt 3.1.0.M1 der offiziellen ChangeLog.txt übernommen):

Vorlagen, die ${#request.…} / ${#session.…} verwendet haben, schlagen nach dem Upgrade direkt fehl; diese Werte müssen stattdessen vom Controller ins Model gelegt werden. Das ist eine Migration, die eingeplant werden muss, kein bloßer Versionswechsel.

Wer ist auf dieser Linie

Abhängigkeitszahlen von deps.dev (direkt abgerufen am 2026-09-04, von jedem reproduzierbar):

Die einzelne Version mit der größten Installationsbasis ist 3.0.11.RELEASE — 36 % höher als das höchste der 3.1-Linie (3.1.3), und sie hat keinen Ausweg innerhalb derselben Linie.

Verwendung

Exit-Codes: 2 = Es gibt Artefakte, deren Versionslinie keine Fix-Version innerhalb derselben Linie hat · 1 = Betroffen, aber Upgrade innerhalb derselben Linie möglich / nicht bestimmbar · 0 = nichts gefunden · 3 = Verwendungs- oder Pfadfehler. Kann direkt in CI eingebunden werden.

Was man am besten scannt

Build-Artefakte scannen (target/*.jar, *.war), nicht das Quellverzeichnis. Thymeleaf wird in den meisten Fällen transitiv über spring-boot-starter-thymeleaf eingebunden, und der Starter selbst trägt keine Version —— im POM ist die Thymeleaf-Version also gar nicht sichtbar. In diesem Fall sagt das Tool explizit „aus dem POM nicht bestimmbar", statt es als nicht vorhanden zu behandeln.

Drei Erkennungsquellen, nach Zuverlässigkeit sortiert:

1. Implementation-Version im MANIFEST —— erkennt auch JARs, die von Repackaging-Tools umbenannt wurden. (Das offizielle Thymeleaf-JAR hat unter META-INF/ nur MANIFEST.MF, kein maven/-Verzeichnis, daher ist dies für Thymeleaf die robusteste Quelle.)
2. Maven-Metadaten pom.properties
3. JAR-Dateiname

BOOT-INF/lib/ und WEB-INF/lib/ in fat JARs / WARs werden einzeln auseinandergenommen, und auch die MANIFEST-Dateien eingebetteter JARs werden gelesen.

Die beiden CVEs sind zwei verschiedene Mechanismen

Der betroffene Bereich des zweiten CVE umfasst 3.1.4, wer also gemäß dem ersten Advisory auf 3.1.4 aktualisiert hat, fällt unter den zweiten.

Aber das sollte man nicht als „offiziell nicht sauber gefixt" lesen —— die beiden Advisories beschreiben unterschiedliche Mechanismen, und die beiden offiziellen Versionen 3.1.4 (2026-04-12) und 3.1.5 (2026-04-21) liegen neun Tage auseinander. Kein offizieller Text besagt, dass der erste Fix unvollständig war. Dieses Tool stellt nur die Fakten nebeneinander, ohne dir diese Schlussfolgerung abzunehmen.

Woher die Entscheidungstabelle stammt und wie man prüft, dass sie noch stimmt

Jede Zahl in RuleTable.java lässt sich nachvollziehen:

Es gleicht die Entscheidungstabelle mit zwei Primärquellen ab —— den betroffenen Bereichen und der versionsweisen Auflistung von OSV sowie der maven-metadata.xml von Maven Central —— bei Abweichungen wird mit einem Exit-Code ungleich null beendet.

Drei Vereinbarungen:

• Bei fehlgeschlagenem Datenabruf Exit-Code 2, mit der Meldung „nicht verifiziert", nicht „Verifizierung bestanden". Ein Netzwerkausfall darf nicht als „alles korrekt" gelesen werden.
• Nur verifizieren, Code nicht automatisch ändern. Wenn sich Zahlen ändern, muss ein Mensch prüfen, wie es dazu kam.
• Es beobachtet gezielt zwei Dinge, die dieses Tool veralten lassen könnten:Wurde 3.1.6 veröffentlicht? und Gibt es plötzlich ein 3.0.16 auf der 3.0-Linie?

Build

Die Null-Abhängigkeit zur Laufzeit ist beabsichtigt: Ein Prüfwerkzeug muss in jede beliebige Umgebung geworfen und direkt ausgeführt werden können.

License

Apache-2.0