CVE-2026-63490

The SpringTemplateLoader in Handlebars.java's handlebars-springmvc module resolves Spring MVC view names into URLs through Spring's ResourceLoader without the path-containment check that was added to the library's other URL-based loaders, leaving the automatically appended '.hbs' suffix as the only guard against reading files outside template directories. A trailing '#' character in a user-influenced view name pushes that suffix into the URL fragment, which both Spring's resource handling and the JDK silently discard, so a view name of 'file:/etc/passwd' reads /etc/passwd instead of /etc/passwd.hbs. The fetched file is then parsed as a Handlebars template and rendered into the HTTP response, giving an unauthenticated, network-reachable attacker an arbitrary file read of any file readable by the JVM process (CVSS 7.5 High). Affected deployments are Spring MVC applications using a default-configured HandlebarsViewResolver whose controllers return fully or partially attacker-controlled view names. No public proof-of-concept is known, exploitation has not been observed in the wild, and the issue is not in CISA KEV; EPSS puts 30-day exploitation probability at about 0.5%.

What to do: Upgrade handlebars-springmvc to a release that applies the missing path-containment check once available (no fixed version is stated in the source data; commit d177cdee shows the intended hardening pattern). As an interim mitigation, stop letting raw user input determine view names, or validate/allowlist view names and reject values containing '#' or scheme prefixes such as 'file:' and 'classpath:'. Also review which secrets are readable by the application's JVM user, since any of those files can be exfiltrated via template rendering until patched.