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
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Handlebars.precompile() generates JavaScript source that is commonly embedded in browser <script elements. Before the fix, static template text containing </script was emitted unchanged. HTML parsers recognize </script even inside a JavaScript string literal, closing the surrounding script element and allowing following attacker-controlled markup to be parsed and executed. This affects applications that precompile attacker-controlled templates and embed the generated source directly in an HTML <script element. It does not affect ordinary server-side rendering or precompiled templates delivered as external JavaScript files. Details Static text is serialized by quotedString() in lib/handlebars/compiler/code-gen.js. The generated JavaScript is valid, but JavaScript quoting alone does not make it safe to embed in HTML. In HTML script data, the sequence </script terminates the element regardless of JavaScript string context. On affected releases, this template: could produce…
Recommended action: Upgrade to 4.7.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Handlebars.compile() and Handlebars.precompile() accept a pre-parsed AST as well as a template string. Handlebars 4.7.9 added validation for such ASTs. It only checks values on PathExpression, NumberLiteral and BooleanLiteral nodes, and the compiler still writes several other AST values into the generated JavaScript unchecked. If an application passes an untrusted object to compile() or precompile(), such as a parsed JSON request body, that object can carry arbitrary JavaScript. With compile(), the code runs on the server when the template renders. With precompile(), it ends up in the precompiled output and runs wherever that output is loaded. Applications that only ever pass template strings are not affected. This bypasses the AST validation added in 4.7.9 for GHSA-2w6w-674q-4c4q, GHSA-xhpv-hc6g-r9c6 and GHSA-3mfm-83xf-c92r. Details The 4.7.9 validator runs in parseWithoutProcessing() and walks the whole AST. It only checks values on nodes whose type is PathExpression,…
Recommended action: Upgrade to 4.7.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Handlebars can expose the Function constructor despite its prototype-access deny list. When a template reaches Function.prototype, its own constructor property is returned before the deny list is checked. An attacker who can render a controlled template with allowProtoMethodsByDefault: true can inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. Description lookupProperty trusts own properties: Normally, prototype-derived values reach resultIsAllowed, which blocks dangerous method names such as constructor. However, constructor is itself an own property of prototype objects: As a result, once a template reaches Function.prototype, looking up constructor returns Function without consulting the deny list. Proof of Concept An attacker needs to reach any prototype object where constructor is an own property, then access constructor to obtain Function. The shortest path requires only an accessible function in the template context: 1. Access a…
Recommended action: Upgrade to 4.7.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The prototype method blocklist in lib/handlebars/internal/proto-access.js blocks constructor, defineGetter, defineSetter, and lookupGetter, but omits the symmetric lookupSetter. This omission is only exploitable when the non-default runtime option allowProtoMethodsByDefault: true is explicitly set — in that configuration lookupSetter becomes accessible while its counterparts remain blocked, creating an inconsistent security boundary. 4.6.0 is the version that introduced protoAccessControl and the allowProtoMethodsByDefault runtime option. Description In lib/handlebars/internal/proto-access.js: All four legacy accessor helpers (defineGetter, defineSetter, lookupGetter, lookupSetter) were involved in the exploit chain addressed by CVE-2021-23383. Three of the four were explicitly blocked; lookupSetter was left out. When allowProtoMethodsByDefault: true is set, any prototype method not present in methodWhiteList is permitted by default. Because lookupSetter is absent from the…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In lib/handlebars/runtime.js, the container.lookup() function uses container.lookupProperty() as a gate check to enforce prototype-access controls, but then discards the validated result and performs a second, unguarded property access (depths[i][name]). This Time-of-Check Time-of-Use (TOCTOU) pattern means the security check and the actual read are decoupled, and the raw access bypasses any sanitization that lookupProperty may perform. Only relevant when the compat compile option is enabled ({compat: true}), which activates depthedLookup in lib/handlebars/compiler/javascript-compiler.js. Description The vulnerable code in lib/handlebars/runtime.js (lines 137–144): container.lookupProperty() (lines 119–136) enforces hasOwnProperty checks and resultIsAllowed() prototype-access controls. However, container.lookup() only uses lookupProperty as a boolean gate — if the gate passes (result != null), it then performs an independent, raw depths[i][name] access that circumvents any…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Handlebars CLI precompiler (bin/handlebars / lib/precompiler.js) concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. Description lib/precompiler.js generates JavaScript source by string-interpolating several values directly into the output. Four distinct injection points exist: 1. Template name injection template.name is derived from the file system path. A filename containing " or ']; breaks out of the string literal and injects arbitrary JavaScript. 2. Namespace injection (-n / --namespace) opts.namespace is emitted as raw JavaScript. Anything after a ; in the value becomes an additional JavaScript statement. 3. CommonJS path injection (-c / --commonjs) opts.commonjs is interpolated inside…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A crafted object placed in the template context can bypass all conditional guards in resolvePartial() and cause invokePartial() to return undefined. The Handlebars runtime then treats the unresolved partial as a source that needs to be compiled, passing the crafted object to env.compile(). Because the object is a valid Handlebars AST containing injected code, the generated JavaScript executes arbitrary commands on the server. The attack requires the adversary to control a value that can be returned by a dynamic partial lookup. Description The vulnerable code path spans two functions in lib/handlebars/runtime.js: resolvePartial(): A crafted object with call: true satisfies the first branch condition (partial.call) and causes an early return of the original object itself, because none of the remaining conditionals (string check, options.partials lookup, etc.) match a plain object. The function returns the crafted object as-is. invokePartial(): When resolvePartial returns a…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. {{n}}), the compiled template calls lookupProperty(decorators, "n"), which returns undefined. The runtime then immediately invokes the result as a function, causing an unhandled TypeError: ... is not a function that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a try/catch is vulnerable to a single-request Denial of Service. Description In lib/handlebars/compiler/javascript-compiler.js, the code generated for a decorator invocation looks like: When "n" is not a registered decorator, lookupProperty(decorators, "n") returns undefined. The expression immediately attempts to call undefined as a function, producing: Because the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and — when not caught by the application — crashes the Node.js…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The @partial-block special variable is stored in the template data context and is reachable and mutable from within a template via helpers that accept arbitrary objects. When a helper overwrites @partial-block with a crafted Handlebars AST, a subsequent invocation of {{ @partial-block}} compiles and executes that AST, enabling arbitrary JavaScript execution on the server. Description Handlebars stores @partial-block in the data frame that is accessible to templates. In nested contexts, a parent frame's @partial-block is reachable as @parent.partial-block. Because the data frame is a mutable object, any registered helper that accepts an object reference and assigns properties to it can overwrite @partial-block with an attacker-controlled value. When {{ @partial-block}} is subsequently evaluated, invokePartial receives the crafted object. The runtime, finding an object that is not a compiled function, falls back to dynamically compiling the value via env.compile(). If that…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Handlebars.compile() accepts a pre-parsed AST object in addition to a template string. The value field of a NumberLiteral AST node is emitted directly into the generated JavaScript without quoting or sanitization. An attacker who can supply a crafted AST to compile() can therefore inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. Description Handlebars.compile() accepts either a template string or a pre-parsed AST. When an AST is supplied, the JavaScript code generator in lib/handlebars/compiler/javascript-compiler.js emits NumberLiteral values verbatim: Because the value is not wrapped in quotes or otherwise sanitized, passing a string such as {},{})) + process.getBuiltinModule('childprocess').execFileSync('id').toString() // as the value of a NumberLiteral causes the generated eval-ed code to break out of its intended context and execute arbitrary commands. Any endpoint that deserializes user-controlled JSON and passes the result…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
resolvePartial() in the Handlebars runtime resolves partial names via a plain property lookup on options.partials without guarding against prototype-chain traversal. When Object.prototype has been polluted with a string value whose key matches a partial reference in a template, the polluted string is used as the partial body and rendered without HTML escaping, resulting in reflected or stored XSS. Description The root cause is in lib/handlebars/runtime.js inside resolvePartial() and invokePartial(): hasOwnProperty is never checked, so if Object.prototype has been seeded with a key whose name matches a partial reference in the template (e.g. widget), the lookup succeeds and the polluted string is returned. The runtime emits a prototype-access warning, but the partial is still resolved and its content is inserted into the rendered output unescaped. This contradicts the documented security model and is distinct from CVE-2021-23369 and CVE-2021-23383, which addressed data…
Recommended action: Upgrade to 4.7.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The package handlebars before 4.7.7 are vulnerable to Prototype Pollution when selecting certain compiling options to compile templates coming from an untrusted source.
Recommended action: Upgrade to 4.7.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Handlebars before 4.4.5 allows Regular Expression Denial of Service (ReDoS) because of eager matching. The parser may be forced into an endless loop while processing crafted templates. This may allow attackers to exhaust system resources.
Recommended action: Upgrade to 4.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Handlebars before 3.0.8 and 4.x before 4.5.3 is vulnerable to Arbitrary Code Execution. The lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript. This can be used to run arbitrary code on a server processing Handlebars templates or in a victim's browser (effectively serving as XSS).
Recommended action: Upgrade to 4.5.3 or 3.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The package handlebars before 4.7.7 are vulnerable to Remote Code Execution (RCE) when selecting certain compiling options to compile templates coming from an untrusted source.
Recommended action: Upgrade to 4.7.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It is due to an incomplete fix for a previous issue. This vulnerability can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting). Recommendation Upgrade to version 3.0.8, 4.5.3 or later.
Recommended action: Upgrade to 4.5.3 or 3.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to prototype pollution. It is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions. Recommendation Upgrade to version 3.0.8, 4.5.3 or later.
Recommended action: Upgrade to 4.5.3 or 3.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of handlebars prior to 3.0.8 or 4.5.2 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting). The following template can be used to demonstrate the vulnerability: Recommendation Upgrade to version 3.0.8, 4.5.2 or later.
Recommended action: Upgrade to 4.5.2 or 3.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of handlebars are vulnerable to Denial of Service. The package's parser may be forced into an endless loop while processing specially-crafted templates. This may allow attackers to exhaust system resources leading to Denial of Service. Recommendation Upgrade to version 4.4.5 or later.
Recommended action: Upgrade to 4.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of handlebars prior to 4.0.14 are vulnerable to Prototype Pollution. Templates may alter an Objects' prototype, thus allowing an attacker to execute arbitrary code on the server. Recommendation For handlebars 4.1.x upgrade to 4.1.2 or later. For handlebars 4.0.x upgrade to 4.0.14 or later.
Recommended action: Upgrade to 4.1.2, 4.0.14 or 3.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of handlebars prior to 4.0.0 are affected by a cross-site scripting vulnerability when attributes in handlebar templates are not quoted. Proof of Concept Template: Input: Rendered result: Recommendation Update to version 4.0.0 or later. Alternatively, ensure that all attributes in handlebars templates are encapsulated with quotes.
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.