Handlebars.java CVE-2026-63490

Exploitation requires two specific conditions to both be true: (1) the target application includes the handlebars-springmvc module with HandlebarsViewResolver configured as the view resolver, and (2) at least one Spring MVC controller endpoint exists where user-supplied input - such as a query parameter, path variable, or request header - directly determines or materially influences the view name string returned by the controller. This is not a default Spring MVC behavior; it represents an explicit design choice to delegate dynamic view selection to user input. Exploitation is further limited by the JVM process's file access permissions - only files readable by the application's OS user account can be retrieved. Applications using the core Handlebars.java library without the handlebars-springmvc adapter are entirely unaffected.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) characterizes this as a high-severity, network-exploitable, unauthenticated vulnerability requiring no user interaction - metrics that are accurate given a vulnerable controller pattern is present. However, the real-world attack surface is narrower than the raw score implies: exploitation is gated on the application exposing a Spring MVC controller that routes user-supplied input directly into view name resolution, which is a specific (and avoidable) architectural pattern rather than a default Spring MVC behavior. EPSS data was not provided, so probabilistic exploitation likelihood cannot be quantified. No KEV listing and no public POC are known at time of analysis, suggesting this has not yet attracted widespread attacker interest. The confidentiality impact is genuinely high for affected deployments because the JVM can access sensitive resources such as application.properties, database credentials, and internal configuration files. Overall: organizations running handlebars-springmvc before 4.5.3 with dynamic view selection should treat this as a priority patch, but those without user-influenced view name controllers face no practical exposure.

An attacker finds a Spring MVC application using Handlebars.java before 4.5.3 with an endpoint such as GET /render?view=home that passes the view parameter directly to HandlebarsViewResolver. The attacker submits GET /render?view=file:/etc/passwd%23, causing HandlebarsViewResolver to construct the URL file:/etc/passwd#.hbs; Java's URL resolution discards the fragment, and the JVM reads and returns the contents of /etc/passwd as a rendered template. No authentication or prior reconnaissance beyond identifying the vulnerable endpoint is required.