
Vérificateur hors ligne pour Thymeleaf CVE-2026-40477 / CVE-2026-41901 — vous indique à laquelle des deux failles SSTI de CVSS 9.0 vous êtes exposé, et si votre ligne de version dispose d’un correctif (3.0.x : ce n’est pas le cas).
Outil de vérification hors ligne pour Thymeleaf CVE-2026-40477 / CVE-2026-41901 — zéro dépendance, un seul jar, sans connexion réseau.
Deux contournements SSTI avec un score CVSS 9.0, deux versions correctives publiées en neuf jours. Il répond d'abord à « lesquelles me concernent », puis à la question bien plus inconfortable :
Sur ma ligne de version, existe-t-il une version corrective vers laquelle migrer ?
Pour 3.1.x, oui (il suffit de passer à 3.1.5.RELEASE).
Pour 3.0.x et antérieur, non — et c'est précisément la population la plus largement déployée.
Les plages affectées des deux advisories sont indiquées comme introduced: 0 dans OSV :
curl -s https://api.osv.dev/v1/vulns/GHSA-r4v4-5mwr-2fwr | jq '.affected[0].ranges'
# [{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.4.RELEASE"}]}]
Cela signifie que toute la ligne 3.0 est concernée, et la liste détaillée des versions va de 3.0.15.RELEASE jusqu'à 1.0.0.
Or, sur Maven Central, la ligne 3.0 s'arrête à 3.0.15.RELEASE, sans aucune publication ultérieure :
curl -s https://repo1.maven.org/maven2/org/thymeleaf/thymeleaf/maven-metadata.xml \
| grep -o '<version>3\.0\.[^<]*</version>' | tail -1
# <version>3.0.15.RELEASE</version>
Les versions correctives des deux CVE se trouvent sur la ligne 3.1. Les utilisateurs de 3.0.x n'ont donc pas l'option « changer un numéro de version »,
mais uniquement une migration vers une autre ligne majeure — et 3.1 est officiellement une version avec des changements cassants (extrait mot pour mot de la section 3.1.0.M1 du ChangeLog.txt officiel) :
- Removed web-API based expression security objects (#request, #response, #session, #servletContext).
- Removed support for Spring 3.x and Spring 4.x.
- Set minimum JDK compatibility level to JDK 8 project-wide (JDK 17 for thymeleaf-spring6).
Les templates qui utilisent ${#request.…} / ${#session.…} échoueront directement après la montée de version ; ces valeurs devront être placées dans le Model par le Controller.
C'est une migration à planifier, pas un simple changement de numéro de version.
Nombre de dépendances selon deps.dev (lu directement le 2026-09-04, reproductible par quiconque) :
| Version | Nombre de dépendances | CVE concernées | Mise à niveau possible sur la même ligne |
|---|---|---|---|
| 3.0.11.RELEASE | 1124 | Les deux | ❌ Aucune version corrective sur la ligne 3.0 |
| 3.0.15.RELEASE | 678 | Les deux | ❌ Idem, et c'est déjà le terminus de cette ligne |
| 3.0.12.RELEASE | 641 | Les deux | ❌ |
| 3.1.3.RELEASE | 826 | Les deux | ✅ Passer à 3.1.5 |
| 3.1.2.RELEASE | 677 | Les deux | ✅ |
| 3.1.4.RELEASE | 70 | Seulement CVE-2026-41901 | ✅ |
| 3.1.5.RELEASE | 590 | — | Déjà sécurisé |
La version individuelle la plus déployée est 3.0.11.RELEASE, soit 36 % de plus que la plus élevée de la ligne 3.1 (3.1.3), et elle n'a aucune issue sur sa propre ligne.
java -jar thymeleaf-check.jar <chemin vers un répertoire ou un jar/war> [--utf8|--gbk]
$ java -jar thymeleaf-check.jar ./target
[CRITICAL] ./target/myapp.war :: BOOT-INF/lib/thymeleaf-3.0.11.RELEASE.jar
Artefact : thymeleaf version 3.0.11.RELEASE (ligne 3.0, source : MANIFEST(Implementation-Version))
Concerné : CVE-2026-40477 + CVE-2026-41901
Affecté, et la ligne 3.0 ne dispose d'aucune version corrective sur Maven Central (cette ligne s'arrête à 3.0.15.RELEASE).
Code de sortie : 2 = un artefact se trouve sur une ligne de version sans version corrective sur la même ligne · 1 = affecté mais mise à niveau possible sur la même ligne / indéterminable · 0 = rien trouvé · 3 = erreur d'utilisation ou de chemin.
Peut être intégré directement dans un CI.
Analysez les artefacts de build (target/*.jar, *.war), pas les répertoires sources.
Thymeleaf est très majoritairement introduit de manière transitive par spring-boot-starter-thymeleaf, or le starter ne porte pas de version —
le numéro de version de Thymeleaf n'apparaît tout simplement pas dans le pom. Dans ce cas, l'outil indique clairement « impossible de déterminer via le pom », au lieu de considérer que l'artefact n'existe pas.
Trois sources d'identification, classées par fiabilité :
Implementation-Version du MANIFEST — reconnaît même les jars renommés par un outil de reconditionnement.
(Le jar officiel de Thymeleaf ne contient que MANIFEST.MF sous META-INF/, sans répertoire maven/, c'est donc la source la plus fiable pour lui.)pom.propertiesLes répertoires BOOT-INF/lib/ et WEB-INF/lib/ des fat jars / wars sont décomposés et examinés un par un, et le MANIFEST des jars embarqués est également lu.
CVE-2026-40477 | CVE-2026-41901 | |
|---|---|---|
| GHSA | GHSA-r4v4-5mwr-2fwr | GHSA-c9ph-gxww-7744 |
| CVSS | 9.0 | 9.0 |
| Versions affectées | <= 3.1.3.RELEASE | <= 3.1.4.RELEASE |
| Correctif | 3.1.4.RELEASE | 3.1.5.RELEASE |
| Divulgation | 2026-04-15 | 2026-05-04 |
| Formulation officielle | "fails to properly restrict the scope of accessible objects" | "fails to properly neutralize specific constructs", survenant dans un contexte sandboxed (restricted) |
La plage affectée de la seconde inclut 3.1.4, donc ceux qui sont montés à 3.1.4 selon la première advisory tombent dans la seconde.
Mais il ne faut pas y lire « le correctif officiel était incomplet » — les deux advisories décrivent des mécanismes différents,
et les deux versions officielles 3.1.4 (2026-04-12) et 3.1.5 (2026-04-21) sont espacées de neuf jours,
sans aucun texte officiel affirmant que le premier correctif était incomplet. Cet outil se contente de présenter les faits côte à côte, sans tirer cette conclusion à votre place.
Chaque chiffre de RuleTable.java peut être re-vérifié :
python tools/gen_rules.py --show
Il confronte le tableau de décision à deux sources primaires — les plages affectées et la liste détaillée des versions d'OSV, ainsi que le
maven-metadata.xml de Maven Central — et sort avec un code non nul en cas d'écart.
Trois conventions :
mvn package # JDK 17 ; target/thymeleaf-check-0.1.0.jar
mvn test # 19 cas de test
L'absence de dépendances à l'exécution est un choix délibéré : un outil de vérification doit pouvoir être lancé tel quel dans n'importe quel environnement.
Apache-2.0