CVE-2026-40477 : SSTI critique Thymeleaf vers RCE Java

Les faits

L'équipe Thymeleaf a publié le 17 avril 2026 un correctif de sécurité pour la CVE-2026-40477, une faille permettant le contournement du mécanisme de restriction d'accès aux objets Java depuis les expressions de template. Référencée par GitLab Advisory Database et l'agrégateur Vulnerability-Lookup, la vulnérabilité affecte le moteur de templates serveur Thymeleaf jusqu'à la version 3.1.3.RELEASE incluse. Le score CVSS officiel atteint 9.0, avec un vecteur d'attaque réseau, sans authentification ni interaction utilisateur requise. Le défaut résulte d'une faiblesse dans le sandbox d'expressions du moteur : certains objets sensibles, normalement hors d'atteinte des templates, restent accessibles via des constructions d'expressions spécifiques. Combiné à la pratique répandue d'injection de variables utilisateur dans le rendu Thymeleaf, ce bypass ouvre la voie à une Server-Side Template Injection capable d'aboutir à l'exécution de code arbitraire sur le serveur d'application Java. Aucune exploitation publique active n'est confirmée à ce stade, mais des proof-of-concept circulent déjà dans les communautés de chercheurs.

Thymeleaf est intégré par défaut à de nombreuses applications Spring Boot, ce qui amplifie la surface d'exposition. Le scénario de risque le plus courant survient lorsqu'un développeur, par méconnaissance des bonnes pratiques, transmet directement une chaîne issue d'un paramètre HTTP — par exemple un message d'erreur personnalisé, un sujet d'e-mail, ou un nom d'utilisateur — au rendu Thymeleaf via StandardTemplateResolver sans passer par les variables typées. Le bypass autorise alors l'attaquant à invoquer des méthodes Java arbitraires, jusqu'à Runtime.getRuntime().exec() et la prise de contrôle complète du serveur applicatif.

Impact et exposition

Le périmètre concerné est considérable : Thymeleaf est l'un des moteurs de templates les plus utilisés dans l'écosystème Spring, présent dans une part significative des applications Java web déployées en entreprise. Selon les statistiques d'usage publiées par Maven Central, plusieurs millions de téléchargements mensuels documentent l'ampleur de la dépendance. Toutes les applications utilisant une version 3.1.3 ou antérieure et acceptant du contenu utilisateur dans le pipeline de templates sont exposées. La vulnérabilité est particulièrement insidieuse car elle ne déclenche pas d'erreur visible : un attaquant peut tester silencieusement la possibilité d'évasion sandbox via des payloads bénins avant de pivoter vers une exploitation complète. Les contextes les plus à risque incluent les portails self-service, les outils de génération de PDF basés sur Thymeleaf, les moteurs de notifications e-mail, et tout endpoint exposant des aperçus de templates personnalisables. La complexité d'exploitation est qualifiée de faible par la notice CVSS, ce qui signifie qu'un payload générique peut suffire à compromettre une grande partie des cibles vulnérables.

Recommandations immédiates

• Mettre à jour la dépendance org.thymeleaf:thymeleaf vers la version 3.1.4.RELEASE — advisory GitLab Maven Database CVE-2026-40477
• Auditer le code applicatif pour identifier toute alimentation directe de templates par des paramètres utilisateur non validés
• Préférer systématiquement le passage de variables typées via le contexte Thymeleaf plutôt que la concaténation dans la chaîne template
• Activer un Content Security Policy strict sur les pages générées pour limiter les répercussions en cas de compromission
• Mettre en place un WAF avec des règles ciblant les patterns d'injection d'expressions ${T(...)} et *{#...}
• Surveiller les journaux applicatifs à la recherche d'erreurs de parsing d'expression Thymeleaf inhabituelles

Les vulnérabilités d'injection dans les frameworks Java restent un vecteur récurrent. Voir notre analyse récente de la RCE critique n8n via injection, ainsi que l'exploitation WebSocket de Marimo. Pour le panorama complet du mois, consulter le bilan du Patch Tuesday avril 2026 et notre dossier sur la gestion des zero-days en 2026.

Comprendre le mécanisme de Server-Side Template Injection (SSTI) dans Thymeleaf

La Server-Side Template Injection (SSTI) survient lorsqu'une application web incorpore des données utilisateur directement dans un template rendu par le moteur de templates côté serveur. Contrairement à la XSS qui injecte du JavaScript côté client, la SSTI injecte du code exécuté sur le serveur avec toutes les permissions de l'application, jusqu'à l'exécution de commandes système arbitraires. Dans le contexte de Thymeleaf, les expressions utilisées pour le rendu dynamique suivent la syntaxe SpEL (Spring Expression Language), qui peut invoquer des méthodes Java arbitraires si l'entrée utilisateur n'est pas correctement isolée. Le bypass sandbox de CVE-2026-40477 exploite précisément une faiblesse dans les restrictions d'accès aux objets Java depuis les expressions Thymeleaf.

Le scénario d'exploitation typique implique une application Spring Boot qui transmet directement une valeur issue d'un paramètre HTTP au contexte de rendu Thymeleaf. Un développeur qui construit un message d'erreur personnalisé en injectant le paramètre "message" de l'URL dans le template expose potentiellement son application à la SSTI. Un attaquant peut alors passer une expression Thymeleaf malveillante qui invoque T(java.lang.Runtime).getRuntime().exec("whoami"), résultant en une exécution de commande sur le serveur. La correction dans Thymeleaf 3.1.4 renforce les restrictions du sandbox pour bloquer ces invocations non autorisées, même via les constructions d'expressions contournées par le bypass de CVE-2026-40477.

Vecteurs d'exploitation les plus courants dans les applications Spring Boot

L'audit des applications Spring Boot pour identifier les vecteurs de SSTI Thymeleaf doit cibler plusieurs patterns récurrents. Le premier et le plus courant est l'utilisation du retour de chaîne de caractères comme nom de template dans les contrôleurs Spring MVC : lorsqu'un @RequestMapping renvoie une chaîne contenant une expression Thymeleaf construite à partir de données utilisateur, le moteur peut interpréter ces expressions de manière non intentionnelle. Le second pattern risqué est l'utilisation de TemplateEngine.process() directement avec une chaîne construite dynamiquement depuis des entrées HTTP, pratique documentée dans certains projets de génération d'emails ou de notifications dynamiques.

Le troisième vecteur, souvent oublié, est la génération de redirections dynamiques utilisant des paramètres utilisateurs. Si la valeur de la redirection est incluse dans un contexte permettant l'évaluation d'expressions, l'exploitation devient possible même sans accès direct au système de templates. L'outil de scanning statique SpotBugs avec le plugin find-sec-bugs, ou les règles CodeQL dédiées à la SSTI, automatisent la détection de ces patterns dans une base de code Java. Les règles Semgrep disponibles dans le registre communautaire pour Java SSTI sont particulièrement efficaces pour les pipelines CI/CD.

Correction immédiate : mise à jour Maven ou Gradle et validation

La correction prioritaire est la mise à jour de la dépendance Thymeleaf vers la version 3.1.4.RELEASE. Dans un projet Maven, cela implique de modifier le pom.xml pour forcer la version de la dépendance org.thymeleaf:thymeleaf-spring5 ou thymeleaf-spring6. Dans un projet Gradle, la propriété implementation 'org.thymeleaf:thymeleaf:3.1.4.RELEASE' doit être mise à jour. Pour les applications Spring Boot, la propriété thymeleaf.version dans gradle.properties ou pom.xml permet de surcharger la version gérée par le BOM Spring Boot sans modifier la version de Spring Boot elle-même, ce qui simplifie considérablement le processus de mise à jour.

En complément de la mise à jour, une validation renforcée des entrées utilisateurs doit être implémentée pour toutes les routes qui font transiter des données vers le rendu Thymeleaf. La règle fondamentale est de ne jamais passer directement une valeur brute issue d'une requête HTTP comme nom de template ou dans le contexte d'évaluation d'expressions. Les données utilisateurs sont passées en tant que variables liées au modèle de données du template via model.addAttribute() et référencées dans le template via la syntaxe de variables ${variable}, qui échappe automatiquement les expressions dans Thymeleaf standard sans invoquer le moteur SpEL.

Audit de la surface d'attaque dans les dépendances transitives

Un aspect souvent négligé est que Thymeleaf peut être présent en tant que dépendance transitive, inclus par des starters Spring Boot ou des bibliothèques tierces. L'outil OWASP Dependency Check, intégré dans le pipeline CI/CD, peut identifier les versions vulnérables dans toute l'arborescence de dépendances, y compris les dépendances transitives qui n'apparaissent pas dans le pom.xml principal. Cette visibilité complète est essentielle pour garantir que la correction s'applique à toutes les instances de Thymeleaf dans l'application, pas seulement à la référence directe.

Les outils de Software Composition Analysis (SCA) comme Snyk, JFrog Xray ou GitHub Dependabot permettent de scanner automatiquement les dépendances à chaque build et de créer automatiquement des tickets ou des pull requests de mise à jour lors de la publication d'une CVE critique. Cette automatisation réduit le délai entre la publication d'une CVE et sa correction dans la base de code de plusieurs jours à quelques heures pour les équipes correctement équipées. La politique de gestion des dépendances doit également interdire l'utilisation de versions de bibliothèques en fin de vie, en bloquant le déploiement si une dépendance critique n'a pas reçu de mise à jour de sécurité depuis plus de 12 mois.

Détection des tentatives d'exploitation dans les logs applicatifs

Les tentatives d'exploitation de CVE-2026-40477 laissent des patterns caractéristiques dans les logs applicatifs. Les payloads SSTI Thymeleaf typiques contiennent des expressions comme ${T(java.lang, ${#vars ou des syntaxes d'accès aux objets Java via l'EL de Thymeleaf. La mise en place de règles de détection dans le WAF ou dans les solutions de logging pour identifier ces patterns permet de détecter les tentatives d'exploitation actives. ModSecurity avec le ruleset OWASP Core Rule Set (CRS) dispose de règles spécifiques aux SSTI qui peuvent être activées ou renforcées en réponse à cette CVE.

La corrélation des logs applicatifs avec les logs du pare-feu permet d'identifier les sources des tentatives d'exploitation. Les scanners automatisés comme Nuclei, qui disposent de templates pour tester les SSTI Thymeleaf, génèrent des patterns d'accès distinctifs : multiples requêtes sur les mêmes endpoints avec des variations de paramètres contenant des payloads d'injection. L'analyse rétrospective des logs sur les 30 jours précédant la publication du correctif peut révéler des tentatives d'exploitation réussies sur les applications vulnérables exposées à internet, nécessitant une investigation forensique approfondie.

Mesures de défense en profondeur pour les équipes sans fenêtre de maintenance immédiate

Pour les équipes qui ne peuvent pas déployer immédiatement le patch Thymeleaf 3.1.4, des mesures compensatoires de défense en profondeur permettent de réduire significativement le risque d'exploitation. La première mesure est la restriction des droits du compte système exécutant l'application Java : un compte dédié sans droits d'administration système ne peut pas installer de backdoor persistante via une SSTI, même si l'exécution de commandes système est temporairement possible. Le principe de moindre privilège appliqué au compte de service limite drastiquement les actions réalisables après une exploitation réussie.

La mise en place d'une règle WAF bloquant les patterns d'expression Thymeleaf dans les paramètres HTTP constitue une mesure de protection supplémentaire sans impact sur les fonctionnalités légitimes, puisque les paramètres HTTP standards ne devraient jamais contenir de syntaxe de template. Cette règle peut être déployée sur ModSecurity, Nginx avec le module naxsi, ou tout WAF commercial en quelques minutes. L'isolation réseau de l'application exposée, en limitant l'accès depuis les seuls réseaux légitimes via des règles de firewall, réduit également la surface exposée aux attaquants externes potentiels.

Contexte : la montée en puissance des attaques SSTI sur les frameworks Java

CVE-2026-40477 s'inscrit dans une tendance plus large d'exploitation des vulnérabilités de template injection dans les frameworks Java web. Les moteurs de templates Java — Thymeleaf, FreeMarker, Velocity, Pebble — ont tous fait l'objet de CVE SSTI significatives au cours des cinq dernières années, reflétant l'intérêt croissant des chercheurs en sécurité et des acteurs malveillants pour cette catégorie de vulnérabilités. L'exploitation de la SSTI est particulièrement attractive pour les attaquants car elle donne directement accès à l'exécution de code serveur, sans nécessiter d'escalade de privilèges supplémentaire lorsque l'application s'exécute avec des droits suffisants.

La popularité de Spring Boot dans les architectures microservices modernes a amplifié l'impact de ces CVE : là où une vulnérabilité dans un composant monolithique affecte une seule application, la même vulnérabilité dans une bibliothèque partagée par des dizaines de microservices peut compromettre l'ensemble de la surface d'attaque d'une organisation. Cette réalité souligne l'importance des inventaires de dépendances complets et des processus d'alerte automatisés qui peuvent déclencher des actions de remédiation sur l'ensemble du parc applicatif dès la publication d'une CVE critique dans une bibliothèque partagée.

Questions fréquentes sur CVE-2026-40477

Les applications utilisant JSP sont-elles affectées ? Non, CVE-2026-40477 est spécifique au moteur d'expressions SpEL de Thymeleaf et ne s'applique pas aux JSP ni aux autres moteurs comme FreeMarker ou Velocity. Les applications qui utilisent Thymeleaf uniquement comme moteur de rendu pour des templates statiques sans injection de données utilisateurs dans le contexte d'évaluation d'expressions sont également hors de portée de l'exploitation — la vulnérabilité requiert que des données utilisateurs non filtrées atteignent le pipeline d'évaluation des expressions Thymeleaf.

Comment vérifier rapidement si mon application est vulnérable ? Deux étapes : premièrement, vérifier si Thymeleaf version 3.1.3 ou antérieure est présent dans les dépendances via mvn dependency:tree | grep thymeleaf. Deuxièmement, auditer les contrôleurs Spring MVC pour identifier les paramètres HTTP transitant vers le contexte Thymeleaf sans isolation — la combinaison de model.addAttribute avec request.getParameter dans le même bloc de code est un indicateur de risque à examiner manuellement. Ces deux vérifications peuvent être réalisées en moins de 30 minutes sur un projet de taille standard.

Retours d'expérience : incidents SSTI Thymeleaf documentés avant CVE-2026-40477

Bien que CVE-2026-40477 représente un bypass du sandbox d'expressions de Thymeleaf spécifique à la version 3.1.3, des incidents de SSTI liés à Thymeleaf ont été documentés dans le passé, notamment une vulnérabilité similaire (CVE-2023-38286) qui avait affecté certaines configurations Thymeleaf 3.0.x. Ces incidents historiques révèlent un pattern récurrent : la vulnérabilité n'est généralement pas dans le moteur de templates lui-même mais dans la façon dont les développeurs l'utilisent, en transgression des bonnes pratiques de sécurité. La formation des équipes de développement sur les risques liés aux moteurs de templates est donc aussi importante que la mise à jour des bibliothèques pour éliminer durablement cette classe de vulnérabilités.

Les post-mortems d'incidents SSTI publiés par des entreprises de sécurité montrent que les exploitations réussies ciblent systématiquement des fonctionnalités de personnalisation exposées aux utilisateurs : templates d'emails configurables par l'administrateur, messages d'erreur personnalisés, ou systèmes de notification avec des contenus modifiables. Ces fonctionnalités sont souvent développées par des équipes différentes de celles qui gèrent la sécurité applicative, sans revue de sécurité spécifique. L'intégration de règles SAST (Static Application Security Testing) spécifiques aux moteurs de templates dans le pipeline CI/CD est la mesure organisationnelle la plus efficace pour prévenir l'introduction de ce type de vulnérabilité lors du développement de nouvelles fonctionnalités.

Prochaines étapes pour les équipes de sécurité applicative

La gestion de CVE-2026-40477 doit s'inscrire dans une démarche plus large de sécurisation des applications Java en production. Trois actions prioritaires s'imposent aux équipes de sécurité applicative : premièrement, établir un inventaire complet des applications utilisant Thymeleaf en production, qu'elles soient directement maintenues ou hébergées par des tiers, et vérifier leur version de la dépendance. Deuxièmement, implémenter des règles SAST dans les pipelines CI/CD pour détecter automatiquement les patterns de code vulnérables à la SSTI dès leur introduction, avant qu'ils n'atteignent la production. Troisièmement, former les équipes de développement aux bonnes pratiques de sécurité des moteurs de templates, en soulignant que la séparation stricte entre code de template et données utilisateurs est la règle fondamentale à respecter en permanence.

La mise en place d'un programme de revue de sécurité des nouvelles fonctionnalités impliquant des moteurs de templates — incluant une vérification systématique que les données utilisateurs ne transitent pas vers le pipeline d'évaluation des expressions — est la mesure structurelle la plus efficace pour éviter la réintroduction de vulnérabilités similaires à CVE-2026-40477 dans les futures versions des applications. Cette revue, intégrée dans la checklist de validation des pull requests, peut être réalisée en quelques minutes par un développeur formé aux risques SSTI et ne nécessite pas d'expert en sécurité dédié pour chaque revue.

La coordination entre équipes de développement et équipes de sécurité est également essentielle dans la gestion post-CVE. Une fois le patch déployé, il est recommandé de conduire une revue rapide de l'ensemble des controllers Spring MVC pour identifier tout pattern de code qui pourrait présenter un risque résiduel de SSTI, indépendamment de la version de Thymeleaf utilisée. Cette revue, menée sur la base d'une checklist technique documentée, garantit que la mise à jour de bibliothèque est accompagnée d'une amélioration durable des pratiques de développement.

En synthèse, CVE-2026-40477 rappelle que la sécurité des applications Java modernes est un effort collectif impliquant les équipes de développement, de sécurité et d'opérations. La réponse efficace à cette vulnérabilité — mise à jour de Thymeleaf 3.1.4, audit de code, déploiement de règles de détection WAF et formation des développeurs — est representative d'une maturité DevSecOps qui se construit progressivement par l'accumulation de bonnes pratiques et d'outillage adapté. Les organisations qui investissent dans cette maturité réduisent significativement leur exposition aux futures vulnérabilités dans les composants Java partagés.

La vigilance permanente face aux nouvelles CVE affectant les bibliothèques tierces comme Thymeleaf nécessite un abonnement aux flux d'alertes de sécurité pertinents : la liste de diffusion security@spring.io pour l'écosystème Spring, les notifications GitHub Dependabot sur les dépôts de code, et les alertes de la base NVD pour les composants Java critiques. Cette veille proactive, outillée et automatisée, est la condition sine qua non pour maintenir une posture de sécurité applicative robuste face à la découverte continue de nouvelles vulnérabilités dans des composants pourtant largement utilisés et considérés comme matures.