Maintainers of Thymeleaf, a widely used template engine for Java web applications, fixed a rare critical vulnerability that allows unauthenticated attackers to execute malicious code on servers.
The vulnerability, tracked as CVE-2026-40478, is rated 9.1 on the CVSS severity scale and is described as a Server-Side Template Injection (SSTI) issue. Thymeleaf has a sandbox-like protection that prevents user input from executing dangerous expressions, but this flaw allows attackers to bypass those protections.
“Although the library provides mechanisms to prevent expression injection, it fails to properly neutralize specific syntax patterns that allow for the execution of unauthorized expressions,” the developers said in their advisory. “If an application developer passes unvalidated user input directly to the template engine, an unauthenticated remote attacker can bypass the library’s protections to achieve Server-Side Template Injection (SSTI).”
Thymeleaf is the de facto template engine in the Java Spring ecosystem and Spring is the most popular framework for developing web applications in Java. Since Java is still widely used for development in enterprise environments, this vulnerability has the potential to impact numerous business applications.
All Thymeleaf versions before 3.1.4.RELEASE are affected and no work-around exists. Companies are advised to identify which of their applications use Thymeleaf and upgrade to 3.1.4.RELEASE as soon as possible.
Straightforward exploitation
According to researchers from application security testing firm Endor Labs, exploitation is straightforward with no special privileges or conditions required. Attackers just need to control input that reaches Thymeleaf’s expression engine, which is a common pattern in web applications.
Endor Labs notes in their report that Thymeleaf has defense-in-depth layers to block dangerous expressions and in this case two of them failed. For example, a string check scanned the expression text for dangerous patterns, such as the new keyword followed by an ASCII space, T (Spring Expression Language type references) and @ (SpEL bean references in some code paths). However, the check only looked for ASCII space 0x20 characters, but the SpEL’s parser also accepts tab (0x09), newline (0x0A), and other control characters between new and the class name.
Another policy blocked classes that start with java.* from being used inside T() type references, but did not block types from org.springframework.*, ognl.*, or javax.*.
“Since typical Spring applications have spring-core on the classpath, classes like org.springframework.core.io.FileSystemResource were freely constructable, and that class can create arbitrary files on disk,” the researchers said.
As such, Endor Labs was able to easily build a proof-of-concept exploit by combining the two: use a tab character after new and calling the org.springframework.core.io.FileSystemResource class to create a file on disk.
“With the right class, an attacker can escalate from file creation to full remote code execution, for example, instantiating a ProcessBuilder wrapper from a third-party library, or leveraging Spring’s own GenericApplicationContext to register and invoke arbitrary beans,” the researchers explained.
Vulnerabilities in the Java Spring Framework itself have been exploited in the past to compromise web servers, so it’s likely that an easy-to-exploit flaw such as this one will be quickly adopted by attackers.
No Responses