CVE-2026-63490: Path Traversal and Arbitrary File Disclosure in Handlebars.java

The vulnerability CVE-2026-63490 (GHSA-g29j-rwfv-h99w) represents a path traversal flaw in the handlebars-springmvc module of Handlebars.java, a Java port of the Handlebars template engine. The component integrates Handlebars template rendering into the Spring MVC framework, primarily utilizing SpringTemplateLoader and HandlebarsViewResolver to resolve templates dynamically.

The flaw permits unauthenticated remote attackers to bypass path validation mechanisms and read arbitrary files from the server's local file system or accessible classpaths. This vulnerability occurs when application endpoints dynamically determine view names based on user input without strict validation, thereby exposing an attack surface to remote network-based exploitation.

By leveraging specific URL delimiters, adversaries trigger directory navigation paths that escape the intended application templates directory. This results in the complete bypass of validation checks built to restrict access solely to safe view components.

The primary defect resides in a parser differential between Java's network-resource resolvers and Handlebars' suffix enforcement logic within SpringTemplateLoader. To restrict template lookup to authorized templates, Handlebars automatically appends an .hbs extension to requested view names, creating a presumed boundary where only files ending in .hbs are processed.

However, when the resource-loading process is delegated to Spring's ResourceLoader, an attacker can manipulate the path by appending URL query parameters (?) or fragment delimiters (#). Java's internal URL parser recognizes the # character as a URL fragment identifier and discards the fragment, along with the appended .hbs suffix, during the actual file-system or socket-level read. Consequently, the application resolves and reads the target file without the suffix restriction, allowing unauthorized file retrieval.

In addition, the SpringTemplateLoader did not implement any logical bounds checking to enforce directory containment. As a result, the resolved paths were allowed to reference arbitrary local directory locations outside of the configured template base directory prefix.

The vulnerable code path did not perform canonical path boundary checking or URL fragment validation before retrieving resources. In the original implementation of SpringTemplateLoader.getResource(final String location), the input location was directly resolved via loader.getResource(location) without validating if the resulting URL contained unsafe URI components.

The following diagram outlines the execution path that leads to the vulnerability:

The fixing commit 61f43423a337b87db5fec1fe59f0725aaaa38df5 addresses this by applying canonical path normalization and strict URL component validation. The updated SpringTemplateLoader canonicalizes the resolved path using java.nio.file.Paths and verifies that it does not escape the defined prefix directory. Furthermore, the validateNoUnsafeUrlComponents helper function throws an exception if the resolved URL contains either a fragment or a query component.

Exploitation of CVE-2026-63490 requires a Spring MVC application configuration where controller view names are influenced directly by user-controlled parameters. An attacker can transmit a crafted payload over HTTP containing a URI protocol identifier and a URL fragment delimiter, such as file:/etc/passwd# or a classpath resource reference.

When the application processes this request, the controller returns the user-supplied string as the view name, which is subsequently handled by HandlebarsViewResolver. Because the template engine compiles templates using the raw contents of the resolved file, the arbitrary contents of the target file are parsed and returned directly to the user in the HTTP response.

The attack executes with the permissions of the underlying JVM process and requires no prior authentication or administrative privileges. Consequently, the exploit is reliable and has low operational complexity.

The exploitation of this path traversal vulnerability leads to unauthorized disclosure of sensitive local files and application data. Attackers can extract critical credentials, database properties, application source code, and platform configuration parameters.

Because the impact is limited to data disclosure without modifying files or causing direct denial of service, the integrity and availability impacts are rated as None. The base CVSS v3.1 score is evaluated at 7.5 (High) with a vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. At this time, threat intelligence sources indicate that exploitation is limited to proof-of-concept tests and has not been widely observed in active campaign activity.

Organizations running affected modules face substantial risk of informational exposure which could lead to secondary privilege escalation attacks.

The definitive remediation for this vulnerability is to upgrade the com.github.jknack:handlebars.java library to version 4.5.3 or later. This upgrade addresses both the web-layer view resolver parameter checking and the loader-level URL validation mechanisms.

If upgrading immediately is not feasible, developers must refactor controllers to avoid dynamic view resolution based directly on untrusted parameters. Implementing strict allowlists of permissible view names prevents users from supplying arbitrary paths. WAF-level rules can also be established to block requests containing protocol prefixes or URL fragments within parameters destined for view-name resolution.

Following the application of the upgrade, existing deployment assets should be scanned to confirm that legacy vulnerable versions of the jar file have been fully replaced.