Handlebars AST Injection Bypasses Prior Fix, Enables RCE via compile()/precompile() (GHSA-8r5x-fm3f-whwj)

What happened

A newly published GHSA advisory (GHSA-8r5x-fm3f-whwj, tracked as CVE-2026-106446) reports that Handlebars' compile() and precompile() functions accept a pre-parsed AST object in addition to a template string — and that the AST validation added in Handlebars 4.7.9 (for three earlier advisories) is incomplete. According to the report, the validator only checks values on PathExpression, NumberLiteral, and BooleanLiteral nodes. Other fields — notably Program.blockParams.length — are read by the compiler and written directly into generated JavaScript without validation, bypassing the 4.7.9 fix entirely.

The advisory includes a working proof of concept: a crafted JSON object (not a string) passed to Handlebars.compile(), containing a malicious expression under blockParams.length, executes arbitrary code when the compiled template is rendered — demonstrated with a helper that doesn't even need to exist.

Why it matters

Per the advisory, applications that only ever pass template strings to Handlebars are not affected. The risk is specific to applications that pass untrusted objects — such as a JSON-deserialized request field — into compile() or precompile(). In that scenario:

• compile(): arbitrary JavaScript executes server-side in the Node.js process, with the application's privileges — remote code execution.
• precompile(): the injected code is embedded in the precompiled template output and runs wherever that output is later loaded, including in end users' browsers.

Given a reported CVSS of 9.8 and public PoC availability, any Node.js service that accepts template-like input from clients and forwards it into Handlebars' compile path should treat this as high priority.

What defenders should do now

• Audit code paths where request bodies, API payloads, or other untrusted data reach Handlebars.compile() or Handlebars.precompile() — especially where a field could be an object/pre-parsed AST rather than a plain string.
• Enforce strict type checking before compilation: reject any input that is not a string type before it reaches Handlebars.
• Where templates are pre-compiled at build time, consider switching server-side rendering to the Handlebars runtime-only build (handlebars/runtime), which does not expose compile().
• For hunting, review application and error logs for unexpected exceptions thrown from inside Handlebars' generated template functions, or unusual child-process/code-execution activity correlated with template-rendering endpoints.
• Track vendor guidance for a patched Handlebars release that closes this specific AST validation gap, since this is described as a bypass of a prior fix rather than a net-new validation mechanism.

Developing intel

This is a same-day advisory and details — including an official patched version — may evolve. This write-up reflects only what is documented in the GHSA report as of publication. For full technical details, the proof of concept, and credit to the reporting researchers, see the original advisory: GHSA-8r5x-fm3f-whwj.