CVE-2026-40478: From TAB to RCE — Breaking Thymeleaf’s Triple-Layer Expression Sandbox

Utworzone przez Dawid Bakaj • środa, 29.04.2026, 09:41 • Bezpieczeństwo aplikacji webowych, Aktualności cyberbezpieczeństwa, Testy penetracyjne (Case studies, porady)

CVE-2026-40478: Thymeleaf SSTI Sandbox Escape Enabling Unauthenticated RCE

Thymeleaf is the de facto standard server-side template engine for Spring Boot applications. Its tight integration with the Spring ecosystem, natural templating philosophy, and mature tooling have made it the default choice for thousands of production Java applications worldwide. When a sandbox escape surfaces in Thymeleaf’s expression evaluation layer, the blast radius is enormous – and that is precisely what CVE-2026-40478 delivers.

This advisory documents a triple-bypass exploit chain, discovered during offensive security research at VIPentest.com, that defeats every security control Thymeleaf places between user-controlled input and SpEL (Spring Expression Language) evaluation. The result is unauthenticated remote code execution reachable from a single HTTP request. No authentication. No interaction. No exotic dependencies. Just a TAB character in the right place.

A parallel analysis of this vulnerability has been published by Endor Labs: Endor Labs – It’s About Thyme (CVE-2026-40478). The GitHub Security Advisory is tracked as GHSA-xjw8-8c5c-9r79.

Vulnerability Overview

Before dissecting the bypass chain, it is worth understanding why Thymeleaf is a high-value target and what the vulnerability’s metadata tells us about its severity.

The attack surface is any Spring MVC controller that concatenates user-controlled input into the return value (the view name). This is a well-documented anti-pattern, but it remains disturbingly common in production codebases – particularly in redirect handlers, dynamic page routing logic, multi-tenant view selection, and legacy Spring MVC applications that predate modern security guidance.

The Vulnerable Code Pattern

The prerequisite for exploitation is straightforward: user input must flow into the string that Thymeleaf resolves as a view name. The canonical vulnerable pattern looks like this:

@Controller
public class VulnerableController {
    @PostMapping("/endpoint")
    public String handleRequest(@RequestParam("param") String userInput) {
        return "prefix/" + userInput;  // user input flows into view name
    }
}

This pattern appears in several common scenarios:

• Dynamic page routing: Controllers that resolve templates based on URL segments or request parameters (e.g., return "pages/" + pageName;).
• Multi-tenant view selection: Applications that select templates based on tenant identifiers embedded in the request.
• Redirect handlers: Controllers that construct redirect targets from user input without proper validation.
• Legacy Spring MVC applications: Older codebases that predate the widespread awareness of SSTI risks in template engines.

When Thymeleaf receives a view name containing a fragment selector (denoted by the :: separator), it evaluates the fragment expression. If that expression contains SpEL constructs, they are evaluated by Spring’s expression engine. The critical question becomes: what security controls stand between user input and SpEL evaluation, and can they be defeated?

The answer, as this research demonstrates, is that all three layers of defense can be bypassed simultaneously.

Thymeleaf’s Defense-in-Depth Architecture

To appreciate the severity of this exploit, it is essential to understand the layered security architecture that Thymeleaf has built over years of hardening against SSTI attacks. The engine implements three distinct security controls, each designed to catch what the previous layer might miss:

1. Layer 1 – Input Validation (checkViewNameNotInRequest): Before any template processing begins, Thymeleaf checks whether the view name contains expression markers (${, *{, #{, @{, ~{). If detected, the request is rejected outright. This is the first line of defense against expression injection.
2. Layer 2 – SpEL Keyword Scanning (containsSpELInstantiationOrStaticOrParam): Even if an expression reaches the SpEL evaluation stage, a keyword scanner inspects the expression string for dangerous patterns: the new keyword (object instantiation), T() syntax (static type references), and #/param patterns. Detection of any of these triggers an exception.
3. Layer 3 – ACL Type Blocklist (ThymeleafEvaluationContext): As a final safety net, Thymeleaf maintains a blocklist of package name prefixes. Types resolved from blocked packages (e.g., java.lang, javax, org.springframework.context) cannot be instantiated or referenced via SpEL.

This is a textbook defense-in-depth architecture. Each layer is independent, and compromising the system requires defeating all three simultaneously. The fact that this is achievable with a single payload speaks to the subtlety and depth of the vulnerability.

Bypass 1: checkViewNameNotInRequest Evasion

The first layer of defense lives in SpringRequestUtils.java. The method checkViewNameNotInRequest() calls containsExpression(), which scans the raw view name string for SpEL expression markers: ${, *{, #{, @{, and ~{. If any of these two-character sequences appear in the input, processing is immediately halted.

The bypass exploits Thymeleaf’s preprocessing mechanism. Thymeleaf supports preprocessing expressions delimited by __|...|__ markers. These are evaluated before the main template expression is parsed. The key insight is that containsExpression() runs on the raw, pre-preprocessing string, while the actual SpEL evaluation occurs after preprocessing has resolved.

The payload structure is:

../index::$__|{EXPR}|__

Here is why this works:

• The $ character is a literal character that sits outside the preprocessing markers.
• __|{EXPR}|__ is a preprocessing expression. Within preprocessing context, {EXPR} evaluates as a literal string (the curly brace is the expression content).
• containsExpression() scans the raw string and sees $_ – a dollar sign followed by an underscore, not a dollar sign followed by an opening brace. It returns false: no expression detected.
• After preprocessing resolves, the __|{EXPR}|__ portion becomes the literal string {EXPR}. The fragment selector is now ${EXPR} – a valid SpEL expression that proceeds to evaluation.
• The ../index prefix resolves via path traversal to an existing template file, satisfying Thymeleaf’s template existence check.

This is an elegant Time-of-Check-to-Time-of-Use (TOCTOU) vulnerability. The security check and the actual evaluation operate on different representations of the same input. The check sees the pre-preprocessing form; the evaluator sees the post-preprocessing form.

Bypass 2: SpEL Keyword Scanner Evasion via TAB (0x09)

Having bypassed expression detection, the SpEL expression now reaches the second layer of defense: SPELVariableExpressionEvaluator, which calls containsSpELInstantiationOrStaticOrParam(). This scanner looks for dangerous patterns in the expression string, specifically:

• The new keyword followed by whitespace (indicating object instantiation)
• The T( syntax (indicating static type references)
• The # and param patterns (indicating parameter access)

Before scanning, the expression string is passed through ExpressionUtils.normalize(). This normalization function is where the critical vulnerability lies. The normalize() method strips characters according to the following condition:

c != '\n' && (c < '\u0020' || (c >= '\u007F' && c <= '\u009F'))

The TAB character (0x09) satisfies this condition: it is less than 0x20 and it is not a newline (0x0A). Therefore, TAB is stripped during normalization.

Now consider what happens with the expression new ClassName (where represents a literal TAB character):

1. Normalization: normalize() strips the TAB. The resulting string is newClassName.
2. Scanner check: The scanner searches for the pattern new followed by whitespace. In the normalized string newClassName, the character after new is C - not whitespace. The scanner concludes: no new keyword detected.
3. SpEL parsing: However, Spring's SpEL tokenizer receives the original, un-normalized expression -new ClassName. The SpEL tokenizer treats TAB (0x09) as standard whitespace. It tokenizes the input as two tokens: the new keyword and the ClassName type identifier. This produces a valid ConstructorReference AST node.

This is the heart of the vulnerability: a semantic disagreement between two components about what constitutes whitespace. Thymeleaf's normalizer strips TAB, causing the scanner to miss the new keyword. Spring's SpEL parser preserves TAB as whitespace, correctly parsing the instantiation expression. The same technique bypasses both the new keyword detection and the T() static reference detection.

It is worth emphasizing how subtle this is. A single character - the humble horizontal tab, 0x09 - is all it takes to desynchronize two security-critical components. The normalization function's character-stripping logic was almost certainly designed to handle edge cases in expression parsing, not as a security boundary. But when the scanner relies on the normalized form while the evaluator uses the original form, it becomes a security-critical discrepancy.

Bypass 3: ACL Evasion via Jackson and Spring Core

With expression detection and keyword scanning defeated, the final obstacle is Thymeleaf's type-level ACL. The ThymeleafEvaluationContext defines BLOCKED_TYPE_REFERENCE_PACKAGE_NAME_PREFIXES, a blocklist of package prefixes that cannot be referenced via SpEL. This prevents direct access to classes like java.lang.Runtime, java.lang.ProcessBuilder, or org.springframework.context.support.ClassPathXmlApplicationContext.

The bypass is conceptually simple: find powerful classes that are not in the blocklist but are always present in a Spring Boot application. Two such classes fit this requirement perfectly:

• com.fasterxml.jackson.databind.ObjectMapper - present via the spring-boot-starter-web dependency chain (spring-boot-starter-web pulls spring-boot-starter-json, which pulls jackson-databind). This class can serialize data and, critically, create streaming generators that write to arbitrary output targets.
• org.springframework.core.io.FileSystemResource - present via spring-core, a foundational Spring dependency. This class provides an getOutputStream() method that opens a write stream to any filesystem path.

By combining these two classes, the attacker can write arbitrary content to any file path writable by the application's OS user - without ever touching a blocked package.

The exploit uses SpEL's projection operator (.![]) to chain method calls on void-returning methods:

{new	com.fasterxml.jackson.databind.ObjectMapper()
  .createGenerator(
    new	org.springframework.core.io.FileSystemResource('/path/to/file')
      .getOutputStream()
  )}.![{writeRaw('file content'), close()}]

The projection operator iterates over a collection and evaluates an expression for each element. Since writeRaw() and close() return void, wrapping the generator in a single-element collection and using projection is the SpEL-idiomatic way to invoke sequential side-effecting operations.

Complete Exploit Chain

The following diagram illustrates the end-to-end exploit flow, showing how each security control is encountered and defeated in sequence:

Two Paths to Thymeleaf RCE

The exploit chain enables two distinct RCE paths, depending on the target environment:

Path 1: Arbitrary File Write (No Additional Dependencies)

Using Jackson's ObjectMapper and Spring Core's FileSystemResource - both guaranteed to be present in any Spring Boot web application - the attacker can write arbitrary content to any filesystem path writable by the OS user running the application. From arbitrary file write, code execution follows through multiple well-established techniques:

• Cron job injection: Write a cron file to /etc/cron.d/ that executes a reverse shell on a schedule.
• SSH authorized_keys injection: Write the attacker's public key to ~/.ssh/authorized_keys for persistent SSH access.
• Webshell deployment: Write a JSP or other executable file to the application's web root.
• Configuration poisoning: Overwrite application configuration files to inject malicious behavior on the next restart.

This path requires zero dependencies beyond what Spring Boot ships by default, making it universally applicable to all affected applications.

Path 2: Direct RCE (Requires commons-lang3)

If Apache Commons Lang 3 (commons-lang3) is present on the classpath - and it is a transitive dependency in approximately 80% of Spring Boot applications - a more direct path to code execution is available. Using ClassUtils.getClass() and MethodUtils.invokeMethod(), the attacker can reflectively invoke Runtime.exec() directly, bypassing the need for a file-write intermediary. This provides immediate, synchronous command execution on the target server.

Impact Assessment

This Thymeleaf RCE vulnerability is severe due to the combination of several factors:

• No authentication required: The vulnerability is exploitable by any unauthenticated network attacker who can send an HTTP POST request to the vulnerable endpoint.
• No user interaction: Exploitation does not require any action from a legitimate user or administrator.
• Full system compromise: Successful exploitation yields arbitrary code execution with the privileges of the application's OS user, typically leading to full server compromise.
• Wide attack surface: Thymeleaf is the most popular template engine in the Spring Boot ecosystem. Any application that passes user input into view name resolution is vulnerable.
• Default dependencies suffice: The Jackson-based file-write exploit requires only dependencies that ship with every standard Spring Boot web application. No exotic or unusual libraries are needed.
• Scope change: The CVSS vector includes S:C (Scope Changed), reflecting that exploitation of the Thymeleaf vulnerability can impact resources beyond the vulnerable component itself - including the host operating system, network infrastructure, and other co-hosted applications.

Responsible Disclosure Timeline

This vulnerability was disclosed through a coordinated process with Daniel Fernandez (Thymeleaf maintainer) and the Spring Security team:

Root Cause Analysis

Each bypass in the chain stems from a distinct root cause, and understanding these root causes is critical for preventing similar vulnerabilities in the future.

TOCTOU in Expression Detection

The checkViewNameNotInRequest defense performs its check on the raw input string, but the actual expression evaluation occurs after Thymeleaf preprocessing transforms the input. This is a classic Time-of-Check-to-Time-of-Use vulnerability: the security check and the security-sensitive operation do not see the same data. The fix must ensure that expression detection either operates on the post-preprocessing form or explicitly detects preprocessing markers (__|...|__) as potentially dangerous.

Whitespace Semantics Disagreement

The normalize() function and the SpEL tokenizer disagree on what constitutes whitespace. This is a broader category of vulnerability that appears whenever two components in a processing pipeline apply different parsing rules to the same input. The normalize function strips control characters below 0x20 (except newline), while the SpEL tokenizer treats those same characters as whitespace separators. The fix must align the whitespace definitions between these components - or, more robustly, the scanner must operate on the exact same representation that the evaluator will consume.

Incomplete Blocklist

The ACL blocklist approach is inherently fragile. The blocklist was designed to prevent access to obvious attack targets like java.lang.Runtime, but it failed to account for the rich ecosystem of utility classes available in a typical Spring Boot application. Jackson's ObjectMapper and Spring Core's FileSystemResource are both powerful primitives that, when combined, yield file-write capabilities equivalent to direct code execution. This illustrates the fundamental weakness of blocklist-based security: the defender must enumerate every possible dangerous class, while the attacker only needs to find one that was missed. An allowlist approach, while more restrictive, would be fundamentally more secure.

Related CVEs

Two additional CVEs are closely related to this advisory and should be reviewed in conjunction:

• CVE-2026-40477: A separate advisory published simultaneously, covering the ACL blocklist bypass (Bypass #3). This was reported by a prior researcher independently and addresses the BLOCKED_TYPE_REFERENCE_PACKAGE_NAME_PREFIXES evasion via Jackson and Spring Core classes.
• CVE-2026-41901: An incomplete fix bypass of CVE-2026-40478, discovered by Cristian-Alexandru Staicu of Endor Labs. This was addressed in Thymeleaf 3.1.5.RELEASE and is the reason the recommended upgrade target is 3.1.5.RELEASE rather than 3.1.4.RELEASE.

The existence of CVE-2026-41901 underscores the difficulty of patching sandbox escapes incrementally. The initial fix in 3.1.4.RELEASE was insufficient, and a second round of hardening was required. Organizations should ensure they are on 3.1.5.RELEASE or later to be protected against all known bypass variants.

Remediation Guidance

For Application Developers

The most urgent action is to update dependencies. However, a defense-in-depth approach demands addressing the vulnerable code patterns as well:

1. Update immediately to Thymeleaf 3.1.5.RELEASE. If you manage Thymeleaf through Spring Boot's dependency management, update to Spring Boot 3.5.14+, 4.0.6+, or 4.1.0-RC1+.
2. Never pass unvalidated user input into controller return values. The return "prefix/" + userInput; pattern is the attack surface. Eliminate it.
3. If dynamic view selection is required, use a strict allowlist. Map user input to a predefined set of valid view names using a lookup table or enum. Never allow freeform input to influence template resolution.
4. Audit all Spring MVC controllers for the vulnerable pattern. Search your codebase for controller methods where the return value is constructed from request parameters, path variables, or any other user-controlled source.

All technical recommendations for the Thymeleaf and Spring Framework maintainers were communicated directly during the coordinated disclosure process and have been addressed in Thymeleaf 3.1.4.RELEASE and 3.1.5.RELEASE.

Detection and Monitoring

While patching is the definitive remediation, organizations may need to detect exploitation attempts during the patching window. The following indicators can be used:

• WAF rules: Look for the __| and |__ preprocessing markers in HTTP request parameters, particularly in combination with :: (the Thymeleaf fragment selector separator). The presence of TAB characters (0x09) in parameters that normally contain only printable ASCII is also a strong signal.
• Application logging: Monitor for Thymeleaf template resolution errors that reference unexpected template paths or fragment selectors containing SpEL-like syntax.
• File integrity monitoring: Since the primary exploit path involves arbitrary file write, monitor sensitive paths such as /etc/cron.d/, ~/.ssh/authorized_keys, and the application's web root for unexpected modifications.
• Dependency scanning: Use SCA tools to identify all applications in your portfolio that depend on Thymeleaf <= 3.1.3.RELEASE or Spring Boot versions prior to the patched releases.

Broader Lessons for the Security Community

CVE-2026-40478 offers several instructive lessons that extend beyond the Thymeleaf ecosystem:

Normalization mismatches are a vulnerability class. Whenever a security check operates on a normalized form of input while the security-sensitive operation uses the original form (or a differently-normalized form), there is potential for bypass. This pattern appears repeatedly across web application firewalls, input validation routines, and sandboxed expression evaluators. The defense is to ensure that security checks and security-sensitive operations always see the exact same representation of the input.

Blocklists fail in rich ecosystems. The Java/Spring Boot ecosystem ships with hundreds of powerful classes. A blocklist that attempts to enumerate every dangerous class will inevitably miss one. The attacker only needs to find a single class that combines the right capabilities (in this case, streaming output to a file). Allowlists, while more restrictive and potentially requiring more maintenance, are the fundamentally sound approach for sandboxed expression evaluation.

Preprocessing creates TOCTOU surfaces. Any system that transforms input between a security check and the operation that check is meant to protect is susceptible to TOCTOU attacks. Template engine preprocessing, URL normalization, character encoding, and Unicode normalization are all common sources of this pattern. Security checks must either operate on the final (post-transformation) form of the input or explicitly reject any input that will undergo transformation.

Defense-in-depth works - but only until every layer is defeated. Thymeleaf's three-layer security architecture was well-designed in principle. Each layer addressed a different attack vector. But when all three layers share the same fundamental assumptions (that their view of the input matches reality, that their blocklists are complete), a single researcher with enough patience can chain bypasses across all three. True defense-in-depth requires layers with independent failure modes - ideally using different security paradigms (e.g., one layer using a blocklist, another using an allowlist, a third using sandboxing at the JVM level).

How VIPentest Can Help

CVE-2026-40478 was discovered during proactive offensive security research at VIPentest. Our team specializes in identifying zero-day vulnerabilities in widely-deployed frameworks and libraries - the kind of deep, technically nuanced research that automated scanners cannot replicate.

If your organization relies on Spring Boot and Thymeleaf, or any Java-based web framework, our penetration testing services can help you identify whether your applications are exposed to Thymeleaf SSTI vulnerabilities like CVE-2026-40478 and similar Server-Side Template Injection attack vectors. Our approach goes beyond running off-the-shelf scanners: we perform manual code review, custom exploit development, and architecture-level security assessment to find the vulnerabilities that matter.

Our services include:

• Web Application Penetration Testing: Deep-dive manual testing of your Spring Boot applications, including SSTI, expression injection, and deserialization attack vectors.
• Source Code Security Review: Expert review of your Java codebase for vulnerable patterns, with actionable remediation guidance.
• Vulnerability Research and Responsible Disclosure: Proactive identification of zero-day vulnerabilities in the frameworks and libraries your applications depend on.
• Security Architecture Assessment: Evaluation of your application's defense-in-depth posture, including sandbox implementations, input validation, and access control models.

Contact us today to discuss how we can strengthen your application security posture: Contact VIPentest

FAQ