"Wait, Our Template Engine Can Execute Code?"

I've been fielding urgent questions about CVE-2026-40478 in Thymeleaf. Many teams using Java Spring apps with Thymeleaf are now facing a 9.1 CVSS vulnerability that allows unauthenticated attackers to execute arbitrary code.

These questions stem from real Slack conversations with teams worried about their compliance posture and how to prevent future incidents. If you're using Thymeleaf, especially versions before 3.1.4.RELEASE, you need immediate answers.

"Do we actually use Thymeleaf? How do I even check?"

Check your build dependencies. Run mvn dependency:tree | grep thymeleaf or gradle dependencies | grep thymeleaf on your Java Spring projects.

However, the bigger issue might be whether you have a complete inventory of third-party components. PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of software components. If you're only discovering Thymeleaf due to this CVE, you have an inventory problem.

Implement dependency scanning in your CI/CD pipeline. Tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot can automatically flag known vulnerabilities. The aim is to know every library version in production before the next CVE emerges.

"We patched to 3.1.4.RELEASE. Are we done?"

While you've addressed this specific vulnerability, the risk of Server-Side Template Injection (SSTI) remains. Thymeleaf's sandbox protections failed. Are you sure other template engines or code generation tools won't have similar issues?

OWASP ASVS v4.0.3 Section 5.2 covers sanitization and sandboxing requirements. Specifically, V5.2.8 requires strict contextual output encoding. Review your template usage:

• Are you allowing user input directly into template expressions?
• Do you validate and sanitize before processing?
• Can you restrict template functionality to read-only operations?

For SOC 2 compliance, your access control narrative (CC6.1) should detail how you prevent unauthorized code execution. A template engine that executes code from unauthenticated input is a control failure, patched or not.

"How do we test for SSTI vulnerabilities ourselves?"

Static analysis won't reliably catch SSTI vulnerabilities—they depend on runtime behavior and input handling. You need dynamic testing targeting template injection.

Include these test cases in your security testing suite:

1. Expression injection tests: Submit template syntax in input fields (e.g., ${7*7} for Thymeleaf)
2. Sandbox escape attempts: Try accessing system properties or reflection APIs
3. Polyglot payloads: Test multiple template syntaxes since applications often use multiple engines

OWASP ASVS v4.0.3 Requirement V5.3.10 addresses server-side template injection testing. Ensure your penetration testing scope explicitly includes SSTI scenarios.

If you're using automated security scans, verify they include SSTI test cases. Many commercial DAST tools added Thymeleaf-specific checks only after this CVE became public. That's reactive, not proactive.

"Our auditor is asking about defense-in-depth. What does that mean here?"

Defense-in-depth means Thymeleaf's sandbox shouldn't be your only protection against code execution. Multiple controls should fail before an attacker reaches your server's execution context.

Layer your controls:

• Input validation: Reject template syntax characters in user input unless necessary. Use strict allowlists if needed.
• Least privilege execution: Your application server shouldn't run as root or with broad filesystem access. Use container security contexts and AppArmor/SELinux profiles.
• Runtime application self-protection: Tools that monitor application behavior can detect and block SSTI exploitation attempts in real-time.
• Network segmentation: Template processing servers shouldn't have direct access to databases or internal services.

Your compliance documentation should map each control to specific requirements. For ISO 27001, this falls under A.8.24 and A.8.28.

"What's our responsibility versus the framework vendor's?"

Endor Labs provided the technical analysis for the Thymeleaf patch, but the vulnerability was introduced by the Thymeleaf maintainers. You're responsible for running vulnerable code in production, regardless of who wrote it.

NIST Cybersecurity Framework v2.0 Function ID.RA-1 requires you to identify and document asset vulnerabilities. "We trusted Spring" isn't a risk management strategy. You need:

• Vendor security advisories in your monitoring workflow
• SLA requirements in your vendor contracts for security response times
• Fallback plans when vendors don't patch quickly enough

For critical dependencies like template engines, consider contributing to security audits or bug bounty programs.

"How do we prevent this from happening again?"

You can't prevent all vulnerabilities in third-party code, but you can reduce your exposure window and blast radius.

• Shift dependency scanning left: Run checks on every pull request, not just in production. Fail builds on high-severity CVEs.
• Implement runtime monitoring: Application security monitoring should alert on unusual template processing patterns.
• Maintain update cadence: Regular dependency updates keep your update process exercised and reduce the backlog when critical patches drop.
• Document your template security model: Detail which templates accept user input, what validation occurs, and who can modify template files.

Where to go from here

Check your Thymeleaf version today. If you're pre-3.1.4.RELEASE, you have a critical vulnerability that requires no authentication to exploit.

But don't stop at patching. Review your dependency management practices, SSTI testing coverage, and defense-in-depth controls. The next template engine vulnerability is already out there—you just don't know which one yet.

The OWASP Application Security Verification Standard v4.0.3 Chapter 5 provides specific requirements for output encoding and injection prevention. Map your current controls against those requirements and document the gaps. Your next audit will ask about them anyway.