Handlebars.js CVE-2026-106446

Exploitation requires the application to pass an attacker-controllable pre-parsed AST object - not a template string - into Handlebars.compile() or Handlebars.precompile() on an affected version (4.0.0 through 4.7.9). The attacker must be able to inject a JavaScript expression into one of the fields left unvalidated by the 4.7.9 hardening: Program.blockParams.length, a non-PathExpression parameter depth, a non-string StringLiteral.value, or a non-string PathExpression.original. LIMITING FACTORS: applications that compile only template strings (the standard and documented usage) are completely unaffected; the untrusted AST must originate from a source the attacker controls (request body, user-writable storage); and no authentication-level or user-interaction requirement is inherent, but the vulnerable code path is a non-default application design pattern that the vendor explicitly warns against. Fixed in 4.7.10.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8 Critical) presents this as trivially remotely exploitable, but that score materially overstates real-world risk because it ignores the central precondition stated in the description: the vulnerable code path is reached ONLY when an application passes an attacker-controllable pre-parsed AST object (rather than a template string) into Handlebars.compile() or Handlebars.precompile(). The vendor explicitly notes 'Applications that pass only template strings are not affected,' and the patch commit adds documentation warning that ASTs should be treated as code and never sourced from untrusted input - meaning the default and overwhelmingly common usage pattern (compiling string templates) is NOT vulnerable. This is therefore a high-CVSS flaw whose true exploitability is gated by an atypical, insecure application design choice, which belongs under AC/AT rather than being free in the base score. On exploitation signals: no CISA KEV entry is present in the data (not actively exploited per available signals), no public exploit code is referenced, and no EPSS score was provided, so there is no evidence of in-the-wild activity. No SSVC decision data was supplied. The conflict to flag explicitly: CVSS claims AC:L/PR:N (easy, unauthenticated), yet the description's 'attacker who can supply an object instead of a template string' describes a non-default, application-architecture-dependent condition that most deployments will never meet - verify against your own code whether any untrusted AST ever reaches compile/precompile before treating this as Critical.

An application deserializes a Handlebars template AST from an untrusted source (e.g. a JSON request body or user-writable storage) and passes that object directly into Handlebars.compile() or Handlebars.precompile(). The attacker submits a crafted AST embedding a JavaScript expression in an unvalidated field such as PathExpression.original, a non-string StringLiteral.value, Program.blockParams.length, or a non-PathExpression parameter depth; when the compiled template renders (or the precompiled output is loaded), the injected expression executes as code in the server process. No public exploit code or active exploitation is identified in the provided data.