Skip to content

← Public intelligence

Maven package

com.github.jknack:handlebars-springmvc

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5MavenAmendedPublished

    Handlebars.java: Arbitrary file read in SpringTemplateLoader via URL-fragment suffix bypass

    CVE-2026-63490 · GHSA-g29j-rwfv-h99w

    Affected
    • Maven com.github.jknack:handlebars-springmvc < 4.5.3
    Fixed in
    4.5.3· Vendor fix available
    Issue
    com.github.jknack.handlebars.springmvc.SpringTemplateLoader resolves Spring MVC view names into URLs via Spring'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). 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. This boundary is bypassed by a single character: (the URL fragment delimiter). When the view name ends with #, the appended .hbs lands inside the URL fragment. Both Spring's FileUrlResource.exists() (via URI.getSchemeSpecificPart()) and the JDK's URL.openStream() (via URL.getFile()) silently discard the fragment, so the file actually opened is the…

    Recommended action: Upgrade to 4.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →