CVE-2026-40478

What it actually does

Thymeleaf versions 3.1.3.RELEASE and earlier contain an improper input neutralization flaw in expression execution protections. In applications that pass untrusted user-controlled data into Thymeleaf template processing, an attacker may be able to bypass intended expression-injection safeguards and cause unauthorized server-side template expressions to execute. Depending on application context, exposed template features, sandboxing, and runtime permissions, successful exploitation can lead to disclosure of sensitive server-side data, modification of application behavior, or execution of operating-system commands from the Java application process.

Why it matters to the business

A vulnerable application can allow an unauthenticated internet user to turn a template-rendering feature into a path for server compromise. The practical impact can include theft of secrets, session data, configuration values, or customer data; tampering with application output or business logic; service disruption; and, in severe cases, full takeover of the application server. The CVSS severity is high, but exploitation requires a specific unsafe application pattern: user input must be passed directly into Thymeleaf template evaluation. EPSS is currently low and stable, there is no known CISA KEV listing, and no public exploit maturity is reported, so prioritization should focus first on internet-facing applications and code paths that dynamically evaluate templates from user input.

How an attack unfolds

An attacker first identifies an application endpoint where user-supplied input is reflected into, or used to construct, a Thymeleaf template or expression. They then submit crafted expression syntax designed to evade Thymeleaf's intended expression-injection protections in affected versions. If the application evaluates that input as a template rather than treating it as plain data, the malicious expression executes on the server in the context of the Java application. The attacker typically validates execution using harmless arithmetic, string, environment, or error-based probes, then escalates to reading application properties, environment variables, files, or invoking dangerous Java APIs where permitted. In the worst case, the attacker uses the Java runtime's privileges to execute commands, deploy a web shell or backdoor, exfiltrate secrets, or pivot to adjacent services available from the compromised application server.

How to fix it

Upgrade Thymeleaf to 3.1.4.RELEASE or later wherever it is used. Because this is a library vulnerability, remediation requires updating direct and transitive dependencies in all Java applications, rebuilding artifacts, and redeploying affected services. In addition to upgrading, review code for any pattern that treats untrusted input as a Thymeleaf template, fragment, expression, preprocessing expression, or dynamically constructed template name. User input should be rendered only as data, not evaluated as template syntax. Prefer static templates with model variables, strict allowlists for template selection, contextual output encoding, and separation of user-authored content from server-side template execution. As compensating controls, restrict dangerous runtime permissions, reduce secrets exposed to the application process, block suspicious template-expression payloads at the WAF where feasible, and monitor Java child-process execution from application servers.

How to confirm the fix worked

Confirm that no deployed application packages Thymeleaf 3.1.3.RELEASE or earlier. Use dependency tooling such as Maven dependency:tree, Gradle dependencies, software composition analysis, SBOM scans, and artifact inspection of JAR/WAR/EAR files to verify the effective runtime version is 3.1.4.RELEASE or later. Validate container images and shaded or bundled JARs, not only source manifests. Perform code review and security testing for endpoints that accept user input and render it through Thymeleaf. Regression tests should verify that known template-expression probes are rendered as inert text or rejected, not evaluated. After deployment, confirm application startup logs, dependency reports, and production artifacts all reference the fixed Thymeleaf version.

Typical attack path

1. Find an application using Thymeleaf 3.1.3.RELEASE or earlier, usually through dependency fingerprinting, error messages, build metadata, or behavior of rendered templates.
2. Locate a user-controlled parameter, header, form field, or content field that is passed into Thymeleaf template rendering or expression evaluation.
3. Submit benign template-expression probes to determine whether server-side evaluation occurs.
4. Send crafted expressions that bypass the affected Thymeleaf expression-execution protections.
5. Use successful expression execution to enumerate runtime information such as system properties, environment variables, application configuration, and available classes.
6. Escalate to sensitive data access, server-side request activity, file access, or command execution if the application context and Java permissions allow it.
7. Establish persistence or exfiltrate data if the compromised server has access to credentials, tokens, databases, or internal services.

How to detect it

There is no single reliable product-wide indicator proving exploitation because exploitation depends on application-specific endpoints and payloads. Review web access logs, WAF logs, application logs, Java exception traces, EDR telemetry, process creation logs, container runtime logs, and outbound network logs. Look for requests containing Thymeleaf-style expression syntax, especially repeated probing with arithmetic expressions, class access, Java runtime references, environment or system-property lookups, and attempts to invoke command execution. In application logs, investigate template parsing errors, expression evaluation exceptions, SpEL/OGNL-style evaluation failures, unusual 500 responses following requests with expression delimiters, or unexpected rendering of evaluated values. In host and container telemetry, prioritize signs that the Java application process spawned shell interpreters or command-line utilities, accessed unexpected sensitive files, or initiated unusual outbound connections after suspicious template requests. If threat hunting finds suspicious probes but no follow-on behavior, treat as attempted exploitation; if Java child processes, secret access, file writes in web directories, or unexplained outbound traffic align with the same request timeline, treat as possible successful compromise.

• __${
• ${T(java.lang.Runtime)
• T(java.lang.Runtime).getRuntime()
• getRuntime().exec(
• T(java.lang.ProcessBuilder)
• new java.lang.ProcessBuilder
• java.lang.System.getenv
• T(java.lang.System).getenv
• java.lang.System.getProperties
• T(java.lang.System).getProperties
• org.thymeleaf.exceptions.TemplateProcessingException
• org.thymeleaf.exceptions.TemplateInputException
• org.thymeleaf.standard.expression
• java.lang.RuntimeException: Error resolving template
• Process Create: java
• java -jar
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe -Command

What your security team should do

• Inventory all applications, services, container images, and packaged artifacts that include Thymeleaf, including transitive and shaded dependencies.
• Prioritize remediation for internet-facing applications, authentication-adjacent flows, content-management features, email/template preview functions, admin consoles, and any feature that renders user-submitted content.
• Upgrade Thymeleaf to 3.1.4.RELEASE or later and redeploy affected applications.
• Perform targeted code review for unsafe dynamic template construction, expression evaluation, preprocessing expressions, template fragments, and user-controlled template names.
• Add tests that ensure untrusted input is treated as data and cannot trigger Thymeleaf expression evaluation.
• Harden runtime environments by limiting secrets available in environment variables, restricting filesystem access, and alerting on Java processes spawning shells or command-line utilities.
• Review WAF, application, and EDR telemetry for suspicious template-expression probes and post-exploitation behavior.
• Because EPSS is low, stable, and the issue is not currently in KEV, use risk-based scheduling, but do not defer fixes for exposed applications with dynamic template rendering.