CVE-2026-41901

What it actually does

This is a Server-Side Template Injection vulnerability in Thymeleaf versions before 3.1.5.RELEASE. Thymeleaf includes restricted or sandboxed expression-evaluation contexts intended to prevent dangerous expression execution, but the affected versions do not fully neutralize certain expression constructs. If an application passes attacker-controlled, unsanitized input into Thymeleaf and that input is evaluated inside one of these restricted template contexts, an attacker may cause arbitrary template expressions to execute. Depending on the application runtime, template configuration, Java security posture, and reachable classes, this can lead to server-side code execution, sensitive data disclosure, application state manipulation, or denial of service. The CVSS score is high because successful exploitation can cross trust boundaries and affect confidentiality, integrity, and availability, although exploitation requires a specific vulnerable usage pattern in the application.

Why it matters to the business

Applications that use vulnerable Thymeleaf versions and render untrusted input in affected template contexts may allow attackers to run commands or access sensitive data from the application server. The most severe outcome is compromise of the web application and its underlying runtime, which can lead to credential theft, data exposure, unauthorized changes, service disruption, and lateral movement. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score with no observed 30-day increase, suggesting limited known exploitation activity; however, the CVSS severity and potential for remote code execution justify prompt remediation, especially for internet-facing Java applications. Thymeleaf is widely used in Java web applications, so exposure may exist indirectly through application frameworks or internal services even where it is not obvious from external asset inventories.

How an attack unfolds

An attacker first identifies a web application that uses a vulnerable Thymeleaf release before 3.1.5.RELEASE. They then look for input fields, query parameters, headers, path variables, profile fields, message content, or other user-controlled values that are later rendered through Thymeleaf templates. Exploitation requires the application to insert unsanitized attacker-controlled data into a sandboxed or restricted expression context where Thymeleaf is expected to block dangerous expression execution. The attacker submits crafted Thymeleaf or expression-language payloads designed to bypass the sandbox restrictions. If the value is evaluated instead of treated as plain text, the expression executes on the server. The attacker may begin with harmless arithmetic or string-evaluation probes, then escalate to accessing environment variables, application properties, files, Java classes, or command execution primitives where available. Post-exploitation activity may include dumping secrets, issuing outbound callbacks, spawning shell commands, modifying application data, or using the compromised application runtime as a pivot point. No named threat actors or public exploit maturity were provided, so defenders should prioritize exposure-based remediation rather than assuming active campaign exploitation.

How to fix it

Upgrade Thymeleaf to 3.1.5.RELEASE or later wherever it is used directly or transitively. Review dependency manifests, build files, application containers, and packaged artifacts for vulnerable Thymeleaf libraries, including shaded or bundled copies. If immediate upgrade is not possible, mitigate by ensuring attacker-controlled data is never passed into Thymeleaf expression-evaluation contexts, especially sandboxed or restricted contexts that are expected to neutralize dangerous expressions. Treat untrusted values strictly as data: escape output, use safe text rendering, avoid dynamic template construction, avoid preprocessing untrusted strings, and do not concatenate user input into template expressions. Add application-layer validation for fields rendered into templates, restrict allowed characters where practical, and prefer allowlists for template-driven values. Reduce blast radius by running the application with least-privilege operating-system permissions, limiting outbound network access, protecting secrets from the application process where possible, and monitoring for abnormal Java process behavior.

How to confirm the fix worked

Confirm the deployed application resolves Thymeleaf to 3.1.5.RELEASE or later using build tooling and runtime artifact inspection. For Maven, check dependency trees and packaged JARs; for Gradle, inspect resolved runtimeClasspath dependencies; for containers, inspect the application archive and image layers for thymeleaf JAR versions. Validate that no vulnerable Thymeleaf versions remain in WAR, EAR, JAR, or fat-JAR artifacts. Perform targeted code review for places where request parameters, headers, path variables, stored user content, or externally sourced data are inserted into Thymeleaf templates, especially with expression preprocessing, dynamic templates, inline expressions, or unescaped output. In a safe test environment, submit benign SSTI probes such as arithmetic expressions and confirm they render as inert text rather than being evaluated. Re-run application security tests after upgrading and verify no regression in template rendering behavior. Confirm production deployment by checking application startup logs, dependency inventory, SBOMs, or artifact hashes rather than relying only on source repository changes.

Typical attack path

1. Identify an application that uses Thymeleaf before 3.1.5.RELEASE.
2. Find user-controllable inputs that are reflected or rendered into server-side templates.
3. Send benign template-expression probes to determine whether input is evaluated by Thymeleaf instead of rendered as text.
4. Refine payloads to target sandboxed or restricted expression contexts affected by the bypass.
5. Execute higher-impact expressions to access server-side objects, configuration, files, environment variables, or Java classes.
6. Attempt command execution or application-level manipulation if dangerous runtime primitives are reachable.
7. Use any obtained secrets or runtime access for persistence, data theft, lateral movement, or service disruption.

How to detect it

To determine whether exploitation has already occurred, review web access logs, application logs, WAF logs, reverse-proxy logs, and API gateway logs for template-expression probes or Java expression-language payloads in query strings, form bodies, path parameters, headers, and JSON fields. Look for strings associated with Thymeleaf, Spring Expression Language, Java reflection, class access, command execution, environment-variable access, file reads, and outbound callback testing. Correlate suspicious requests with application errors, template parsing exceptions, 500 responses, unusual response sizes, or subsequent outbound network connections from the application host or container. Review endpoint telemetry, EDR, container runtime logs, and process accounting for Java application processes spawning shells, command interpreters, network utilities, scripting runtimes, or file-transfer tools. Inspect application logs for Thymeleaf parsing or expression-evaluation exceptions around the same timestamps as suspicious requests. Check DNS and proxy logs for outbound callbacks to unknown domains shortly after submitted payloads, as attackers commonly use DNS or HTTP callbacks to confirm server-side execution. If compromise is suspected, preserve relevant application logs, access logs, container images, temporary directories, deployed artifacts, and process execution history before redeploying.

• ${T(java.lang.Runtime).getRuntime().exec
• T(java.lang.Runtime)
• getRuntime().exec
• java.lang.ProcessBuilder
• new java.lang.ProcessBuilder
• T(java.lang.ProcessBuilder)
• ${T(java.lang.System).getenv
• T(java.lang.System).getProperty
• class.forName
• java.lang.Class.forName
• th:inline
• th:utext
• __${
• *{T(java.lang.Runtime)
• #{T(java.lang.Runtime)
• Runtime.getRuntime().exec
• /bin/sh -c
• cmd.exe /c
• powershell.exe
• curl http://
• wget http://
• nslookup
• javax.script.ScriptEngineManager
• org.thymeleaf.exceptions.TemplateProcessingException
• org.thymeleaf.exceptions.TemplateInputException

What your security team should do

• Inventory all Java applications and services that include Thymeleaf, prioritizing internet-facing systems and applications that render user-submitted content.
• Upgrade Thymeleaf to 3.1.5.RELEASE or later and rebuild/redeploy affected applications from clean dependency manifests.
• Search for vulnerable packaged artifacts, including fat JARs and container images that may retain older Thymeleaf libraries after source-level dependency updates.
• Review templates and controller code for unsafe patterns where untrusted input can influence Thymeleaf expressions, dynamic templates, inline expressions, or unescaped output.
• Add detection rules for common SSTI probing strings and suspicious Java child-process execution from application servers.
• Harden runtime permissions so the Java application process cannot write broadly to the filesystem, access unnecessary secrets, or initiate unrestricted outbound connections.
• If exposure is confirmed, perform retrospective log review for SSTI probes, anomalous outbound callbacks, unexpected child processes, and access to sensitive configuration or environment values.
• Because public exploitation is not currently indicated and EPSS is low, align emergency response to actual exposure, but treat confirmed vulnerable internet-facing usage as high priority due to potential server compromise.