Keine Panik: Die Thymeleaf-Template-Injection ist nur gefährlich, wenn Sie sie zulassen (CVE-2026-40478)

Die Thymeleaf-Schwachstelle mit einem CVSS-Score von 9,1 erregt zu Recht Ihre Aufmerksamkeit. Doch bevor Sie Alarm schlagen und sie als das nächste Log4Shell bezeichnen, lesen Sie erst einmal weiter.

CVE-2026-40478 ist eine serverseitige Template-Injection-Schwachstelle in Thymeleaf, die von Pentester Dawid Bakaj entdeckt wurde. Thymeleaf ist eine Java-Template-Engine für das serverseitige Rendering von Webseiten. Die Sandbox, die normalerweise die Ausführung beliebigen Codes verhindert, wurde mithilfe eines Tab-Zeichens umgangen. Und ja, bei einer Ausnutzung kann dies zur Remote-Code-Ausführung führen.

Doch das Wichtigste ist: Diese Schwachstelle betrifft Sie nur, wenn Ihr Code bereits etwas tut, was er nicht tun sollte.

Wovor die Sandbox schützt

Thymeleaf verfügt über eine Sicherheits-Sandbox. Sie schränkt ein, was SpEL-Ausdrücke (Spring Expression Language) bei der Auswertung dynamischer Inhalte tun können. Die Sandbox ist für einen bestimmten Fall vorgesehen: wenn benutzergesteuerte Eingaben irgendwie die Ausdrucks-Engine von Thymeleaf erreichen.

Wenn das in Ihrem Code nie geschieht, kommt die Sandbox nie zum Einsatz, und diese CVE betrifft Sie nicht. Die richtige Verwendung von Thymeleaf ist einfach: Benutzereingaben fließen in das Datenmodell. Das Template bleibt meistens als HTML-Datei statisch.

Java-Code:

@GetMapping("/greet/safe")
public String greetSafe(@RequestParam String name, Model model) {
   model.addAttribute("name", name);
   return "greet";
}

Thymeleaf-Template:

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<body>
   <p th:text="${name}">Default name</p>
</body>
</html>

Thymeleaf rendert den Wert von name. Der Wert wird niemals als Ausdruck geparst. Ein Angreifer kann als name, beliebige Payloads senden – es passiert nichts Interessantes. Genau so ist es konzipiert. So sollte Thymeleaf funktionieren.

Missbrauch der Template-Engine

Die Schwachstelle lässt sich ausnutzen, wenn ein Entwickler zulässt, dass Benutzereingaben direkt die Ausdrucks-Engine erreichen. In diesem Fall wird das Framework falsch verwendet. Das ist zwar möglich, aber recht schwierig – insbesondere, wenn Thymeleaf mit Spring Boot verwendet wird.

@ResponseBody
@GetMapping("/greet/unsafe")
public String greetUnsafe(@RequestParam String name, Model model) {
   Context context = new Context();
   SpringTemplateEngine templateEngine = new SpringTemplateEngine();
   templateEngine.setTemplateResolver(new StringTemplateResolver());
   context.setVariable(name, name);
   String template = "<p th:text=\"'Hello ' + ${"+ name + "}\">...</p>";
   return templateEngine.process(template, context);
}

Wie der obige Code zeigt, muss ich manuell eine neue Instanz von templateEngine erstellen und einen Resolver festlegen. Normalerweise wird das von Spring bereitgestellt.
Außerdem muss ich die Variable im Kontext festlegen, damit mein normaler, legitimer Anwendungsfall funktioniert.

Im obigen Fall wird die Eingabe des Benutzers jedoch an die Ausdrucks-Engine übergeben. Das ist die Voraussetzung dafür, dass diese CVE relevant ist.

Ein ähnliches Missbrauchsmuster ist die dynamische View-Auflösung. Anstatt Template-Strings direkt zu erstellen, könnte ein Entwickler Views anhand von Benutzereingaben auflösen:

@GetMapping("/page/unsafe")
@ResponseBody
public String showPageUnsafe(@RequestParam String page) {
   Context context = new Context();
   SpringTemplateEngine templateEngine = new SpringTemplateEngine();
   StringTemplateResolver resolver = new StringTemplateResolver();
   resolver.setTemplateMode(TemplateMode.TEXT);
   templateEngine.setTemplateResolver(resolver);
   context.setVariable(page, page);
   String template = "[[${" + page + "}]]";
   return templateEngine.process(template, context);
}

Der Anwendungsfall ist legitim: Ein Endpunkt stellt mehrere Seiten bereit. Doch nun beeinflussen Benutzereingaben, was Thymeleaf parst. Dasselbe Missbrauchsmuster, mit demselben möglichen Exploit. Beachten Sie auch hier, wie viel manuelle Konfiguration nötig ist, um überhaupt so weit zu kommen. Die sichere Variante besteht nach wie vor aus nur drei Zeilen.

@GetMapping("/page/safe")
public String showPageSafe(@RequestParam String page) {
   return page;
}

Wie das Tab-Zeichen die Thymeleaf-Sandbox umgeht

Sobald ein Missbrauchsmuster vorliegt, ist der eigentliche Exploit unkompliziert.

Die Sandbox sucht nach new (dem Schlüsselwort gefolgt von einem Leerzeichen), um die Instanziierung von Objekten zu blockieren. Die Umgehung verwendet stattdessen new[TAB]. Bei der Vorabprüfung wird new nicht gefunden, also wird die Eingabe durchgelassen. SpEL hingegen erkennt den Tabulator als gültiges Leerzeichen und parst den Ausdruck korrekt.

Die Payload sieht so aus:

new[TAB]org.springframework.core.io.FileSystemResource('shell.jsp').getOutputStream()

Nach der Schlüsselwortprüfung wird eine Typ-Blockliste angewendet, die java.*-Klassen blockiert. Spring-Klassen waren jedoch nicht in dieser Liste enthalten. Dadurch konnten aufgrund der unvollständigen Blockliste in Verbindung mit einer schwachen Prüfung auf new Klassen wie FileSystemResource geladen werden. Das führte dazu, dass eine Datei auf die Festplatte geschrieben wurde. Theoretisch kann ein Angreifer so eine JSP-Datei ablegen, die ProcessBuilder aufruft und eine RCE ausführt.

Zwei Schutzmechanismen versagten unabhängig voneinander: ein Problem mit Leerzeichen bei der Schlüsselwortprüfung und eine eng gefasste Blockliste. Die Umgehung gelang, weil die Prüfungen nicht vollständig berücksichtigten, was als Trennzeichen gelten konnte. EndorLabs bietet eine detailliertere Analyse des Exploits, falls Sie mehr erfahren möchten.

Im GitHub-Repository finden Sie funktionierende Beispiele für sicheren und unsicheren Code.

Was Sie tun sollten

Spielen Sie zuerst den Patch ein. Aktualisieren Sie auf Thymeleaf 3.1.4, unabhängig davon, ob Sie glauben, dass Ihr Code betroffen ist. Warten Sie nicht erst die Ergebnisse der Überprüfung ab.

Wenn Sie Thymeleaf über Spring Boot verwenden, aktualisieren Sie einfach das Spring-Boot-Starter-Parent auf die neueste Version (derzeit 3.5.14 oder 4.0.6). Falls Sie feststellen, dass Sie einige Versionen zurückliegen, sollten Sie sich die OpenRewrite-Rezepte ansehen, um auf die neueste Version von Spring Boot 3.5 oder Spring Boot 4.0 zu migrieren.

Prüfen Sie nach der Aktualisierung Ihren Code darauf, ob Template-Strings oder die Seitenauflösung dynamisch aus Benutzereingaben erzeugt werden, indem diese direkt an die Template-Engine übergeben werden. In diesem Fall liegt ein Missbrauchsmuster vor. Korrigieren Sie den Code selbst und nicht nur die Bibliotheksversion.

Der CVSS-Score von 9,1 ist real, gilt aber nur unter bestimmten Bedingungen

Ein kritischer CVSS-Score setzt voraus, dass die entsprechende Bedingung erfüllt ist. Wenn Ihr Code Benutzereingaben in die Thymeleaf-Ausdrucks-Engine einspeist, ist ein Score von 9,1 zutreffend und die Auswirkungen sind schwerwiegend. Andernfalls sind Sie von der CVE selbst nicht betroffen. Trotzdem sollten Sie den Patch einspielen!

Die Frage, die Sie Ihrem Team bei der Überprüfung stellen sollten, lautet nicht nur: „Welche Thymeleaf-Version verwenden wir?“ Sie lautet: „Erzeugen wir View-Namen oder Template-Ausdrücke dynamisch aus Anfragedaten?“

Aktualisieren Sie Thymeleaf auf Version 3.1.4 oder höher und klären Sie anschließend diese zweite Frage. Unabhängig von der Antwort sollten Sie Ihre Abhängigkeiten während der Entwicklung weiterhin scannen und sie in der Produktion mit Snyk Open Source. überwachen. Und das Beste: Sie können kostenlos loslegen.