Description

Handlebars.java provides logic-less and semantic Mustache templates with Java. Prior to 4.5.3, com.github.jknack.handlebars.springmvc.SpringTemplateLoader resolves attacker-influenced Spring MVC view names through Spring ResourceLoader without the path-containment validation used by other URL-based loaders. In handlebars-springmvc/src/main/java/com/github/jknack/handlebars/springmvc/SpringTemplateLoader.java, a view name using a file: or classpath: URL and ending with the # fragment delimiter places the appended .hbs suffix in the fragment, which FileUrlResource.exists() and URL.openStream() discard. HandlebarsViewResolver in handlebars-springmvc/src/main/java/com/github/jknack/handlebars/springmvc/HandlebarsViewResolver.java then passes the attacker-controlled name to handlebars.compile(), allowing an unauthenticated remote attacker to read files accessible to the JVM when an application exposes a controller with a user-influenced view name. This issue is fixed in version 4.5.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-20T15:18:04.577Z",
  "pubdate": "2026-08-20T15:18:04.577Z",
  "executiveSummary": "An arbitrary file read vulnerability exists in Handlebars.java prior to version 4.5.3, specifically within the com.github.jknack.handlebars.springmvc.SpringTemplateLoader and HandlebarsViewResolver components. The vulnerability allows an unauthenticated remote attacker to read arbitrary files accessible to the Java Virtual Machine (JVM) by exploiting how attacker-influenced Spring MVC view names are resolved through the Spring ResourceLoader without proper path-containment validation. The impact includes the unauthorized disclosure of sensitive system and application files, posing significant confidentiality risks. Exploitation requires an application configuration where a controller exposes a user-influenced view name. The issue is fully remediated in version 4.5.3.",
  "technicalDetails": "The vulnerability stems from insufficient path-containment validation in com.github.jknack.handlebars.springmvc.SpringTemplateLoader when handling attacker-influenced Spring MVC view names. Unlike other URL-based loaders in Handlebars.java, the SpringTemplateLoader passes view names directly to the Spring ResourceLoader. An attacker can supply a malicious view name utilizing file: or classpath: protocols combined with the # fragment delimiter. The appended .hbs suffix provided by the template engine is placed within the fragment portion of the URL. Methods such as FileUrlResource.exists() and URL.openStream() discard this fragment, leaving the base path fully controlled by the attacker.\nFollowing resource loading, HandlebarsViewResolver in handlebars-springmvc/src/main/java/com/github/jknack/handlebars/springmvc/HandlebarsViewResolver.java passes the attacker-controlled name directly to the handlebars.compile() method. This mechanism allows remote, unauthenticated attackers over the network to traverse the file system or access arbitrary classpath resources that the JVM process has read permissions for.\nThe step-by-step attack flow begins with an attacker identifying an endpoint in a Spring MVC application where controller logic allows user input to directly influence the returned view name. The attacker crafts a malicious HTTP request containing a specialized view name parameter utilizing a file: or classpath: URL scheme, terminating the targeted path with a # character to neutralize the automatically appended .hbs extension. The vulnerable SpringTemplateLoader resolves the targeted resource outside of the intended template directory. The HandlebarsViewResolver compiles the resulting resource, and the application subsequently reflects or discloses the contents of the targeted file within the HTTP response or exposes the system to further compromise depending on the application context."
}