https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 19:03:16 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-63490 <p>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.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-63490 https://vulnerability.circl.lu/vuln/ghsa-g29j-rwfv-h99w <p><strong>Affected:</strong> Maven: com.github.jknack:handlebars-springmvc</p> <p>### Summary `com.github.jknack.handlebars.springmvc.SpringTemplateLoader` resolves Spring MVC view names into URLs via Spring&#39;s `ResourceLoader` **without applying the path-containment check** that protects every other URL-based loader in the project (`ClassPathTemplateLoader`, `FileTemplateLoader`, `ServletContextTemplateLoader` - all hardened by commit `d177cdee`).</p> <p>The only remaining defense for `file:` / `classpath:` view names is the unconditional `.hbs` suffix appended by `AbstractTemplateLoader.resolve(...)`. This suffix is the load-bearing security boundary that prevents a request like `view=file:/etc/passwd` from reading `/etc/passwd` instead of `/etc/passwd.hbs`.</p> <p>**This boundary is bypassed by a single character: `#` (the URL fragment delimiter).**</p> <p>When the view name ends with `#`, the appended `.hbs` lands inside the URL fragment. Both Spring&#39;s `FileUrlResource.exists()` (via `URI.getSchemeSpecificPart()`) and the JDK&#39;s `URL.openStream()` (via `URL.getFile()`) **silently discard the fragment**, so the file actually opened is the bare path the attacker specified - for example `/etc/passwd` rather than `/etc/passwd.hbs`. The compiled &#34;template&#34; is then parsed and rendered into the HTTP response body.</p> <p>Result: **unauthenticated, network-reachable, arbitrary file read** of any file readable by the JVM process on any Spring MVC application that uses a default-configured `HandlebarsViewResolver` and exposes a controller that returns a (fully or partly) user-influenced…</p> <p><strong>Affected:</strong> Maven: com.github.jknack:handlebars-springmvc</p> <p>### Summary `com.github.jknack.handlebars.springmvc.SpringTemplateLoader` resolves Spring MVC view names into URLs via Spring&#39;s `ResourceLoader` **without applying the path-containment check** that protects every other URL-based loader in the project (`ClassPathTemplateLoader`, `FileTemplateLoader`, `ServletContextTemplateLoader` - all hardened by commit `d177cdee`).</p> <p>The only remaining defense for `file:` / `classpath:` view names is the unconditional `.hbs` suffix appended by `AbstractTemplateLoader.resolve(...)`. This suffix is the load-bearing security boundary that prevents a request like `view=file:/etc/passwd` from reading `/etc/passwd` instead of `/etc/passwd.hbs`.</p> <p>**This boundary is bypassed by a single character: `#` (the URL fragment delimiter).**</p> <p>When the view name ends with `#`, the appended `.hbs` lands inside the URL fragment. Both Spring&#39;s `FileUrlResource.exists()` (via `URI.getSchemeSpecificPart()`) and the JDK&#39;s `URL.openStream()` (via `URL.getFile()`) **silently discard the fragment**, so the file actually opened is the bare path the attacker specified - for example `/etc/passwd` rather than `/etc/passwd.hbs`. The compiled &#34;template&#34; is then parsed and rendered into the HTTP response body.</p> <p>Result: **unauthenticated, network-reachable, arbitrary file read** of any file readable by the JVM process on any Spring MVC application that uses a default-configured `HandlebarsViewResolver` and exposes a controller that returns a (fully or partly) user-influenced…</p> https://vulnerability.circl.lu/vuln/ghsa-g29j-rwfv-h99w