CVE-2026-63490

If you use Handlebars.java with Spring MVC, the SpringTemplateLoader has a path traversal vulnerability that you need to address now — not because it's being actively exploited at scale (EPSS sits at 0.0047), but because the vulnerability is straightforward to weaponize and the exposure pattern is more common than you'd think. The bug is a fragment-delimiter bypass. The loader appends .hbs to your view name before passing it to Java's URL handling, but if you supply a name containing # (like ../etc/passwd#), the fragment gets stripped before the file existence check runs. The appended .hbs suffix then applies to whatever's before the #, not the path you actually wanted to traverse. URL.openStream() and FileUrlResource.exists() both strip fragments per RFC 3986 — this is standard behavior, not a bug in the JVM. Here's what makes this architecturally significant: Handlebars.java has multiple template loaders (ClasspathUrlLoader, FileUrlLoader), and the ones that load from URLs or files already have explicit path-containment guards. SpringTemplateLoader didn't inherit those guards. That wasn't an accident of oversight — it's a structural pattern where framework integrations get added as convenience layers without receiving the same security scrutiny as the core library. When you layer Spring's deliberately flexible ResourceLoader semantics on top of a template engine that assumes you control the template source, you're importing Spring's flexibility into a context that may not be designed to contain it. The practical risk: if your Spring MVC application exposes a controller endpoint where the view name comes from a request parameter — a pattern used in dynamic view resolution, generic view controllers, and some MVC scaffolding — an attacker supplying a path like ../../../WEB-INF/web.xml# can read arbitrary files that the process has access to. This isn't theoretical; it's the same attack class documented in CVE-2020-5398 (RFD) and CVE-2019-12402, where fragment stripping was flagged as a bypass vector in Spring's resource handling. What to do: first, determine whether your application passes user-influenced data into any view-resolution logic that uses Handlebars. If it does, treat that as a direct path to exploitation regardless of whether the parameter looks 'safe.' Second, audit any Handlebars.template() calls that accept external input — the vulnerability is in the loader's resolution logic, not in template execution, so input sanitization at the controller layer doesn't help if the loader itself is receiving the malicious path. Third, check your Handlebars.java version; the patch adds path-validation to SpringTemplateLoader that mirrors what's already present in ClasspathUrlLoader and FileUrlLoader. If you're on a version predating mid-2026 and use Spring integration, assume exposure until you can confirm the loader isn't reachable from untrusted input. The deeper lesson is that library integrations with framework-specific resource loading systems carry hidden trust-boundary assumptions. Spring's ResourceLoader is designed to be flexible — that's its value — but that flexibility becomes a liability when it hands off to a library that expects to control its own file access. This isn't unique to Handlebars; it's a recurring pattern across Java template ecosystems. When you compose libraries with mismatched threat models, the composition itself becomes the vulnerability.

Reviewed through automated stages and approved by a human before publication.