Skip to content

GHSA-9cx6-37pm-9jff CVE-2026-33939

Handlebars.js has Denial of Service via Malformed Decorator Syntax in Template Compilation

High npm
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.63%
Chance of exploitation in the next 30 days. Higher than 50.07% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-754 Improper Check for Unusual or Exceptional Conditions
Fix
4.7.9
Upgrade handlebars to this version or later

Description

Summary

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:

fn = lookupProperty(decorators, "n")(fn, props, container, options) || fn;

When "n" is not a registered decorator, lookupProperty(decorators, "n") returns undefined. The expression immediately attempts to call undefined as a function, producing:

TypeError: lookupProperty(...) is not a function

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 process.

This inconsistency is notable: references to unregistered helpers produce a clean "Missing helper: ..." error, while references to unregistered decorators cause a hard crash.

Attack scenario: An attacker submits {{*n}} as template content to any endpoint that calls Handlebars.compile(userInput)(). Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS.

Proof of Concept

const Handlebars = require('handlebars'); // Handlebars 4.7.8, Node.js v22.x

// Any of these payloads crash the process
Handlebars.compile('{{*n}}')({});
Handlebars.compile('{{*decorator}}')({});
Handlebars.compile('{{*constructor}}')({});

Expected crash output:

TypeError: lookupProperty(...) is not a function
    at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36))

Workarounds

  • Wrap compilation and rendering in try/catch:
    try {
      const result = Handlebars.compile(userInput)(context);
      res.send(result);
    } catch (err) {
      res.status(400).send('Invalid template');
    }
    
  • Validate template input before passing it to compile(). Reject templates containing decorator syntax ({{*...}}) if decorators are not used in your application.
  • Use the pre-compilation workflow: compile templates at build time and serve only pre-compiled templates; do not call compile() at request time.

Affected versions

npm

PackageVulnerableFixed in
handlebars
>= 4.0.0, < 4.7.9
4.7.9

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

handlebars npm → 4.7.9

npm
npm install handlebars@4.7.9
yarn
yarn add handlebars@4.7.9
pnpm
pnpm add handlebars@4.7.9

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-754: Improper Check for Unusual or Exceptional Conditions

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

How to prevent it
  • Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
  • Implementation: Check the results of all functions that return a value and verify that the value is expected.
  • Implementation: If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
  • Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Architecture and Design, Implementation: If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
  • Architecture and Design: Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-8r5x-fm3f-whwj
Handlebars: JavaScript Injection via AST Type Confusion in compile (bypass of CVE-2026-33937)
Critical Also affects handlebars
GHSA-p8wg-vrv2-v86f
Handlebars: JavaScript Injection via Own Property Check Bypass
Critical Also affects handlebars
GHSA-xw65-4hp5-5hc7
Handlebars: JavaScript Injection via Unsafe Inline Embedding of Precompiled Templates
Medium Also affects handlebars
GHSA-7rx3-28cr-v5wh
Handlebars.js has a Prototype Method Access Control Gap via Missing __lookupSetter__ Blocklist Entry
Medium Also affects handlebars
GHSA-442j-39wm-28r2
Handlebars.js has a Property Access Validation Bypass in container.lookup
Low Also affects handlebars
GHSA-xjpj-3mr7-gcpf
Handlebars.js has JavaScript Injection in CLI Precompiler via Unescaped Names and Options
High Also affects handlebars
GHSA-xhpv-hc6g-r9c6
Handlebars.js has JavaScript Injection via AST Type Confusion when passing an object as dynamic partial
High Also affects handlebars
GHSA-3mfm-83xf-c92r
Handlebars.js has JavaScript Injection via AST Type Confusion by tampering @partial-block
High Also affects handlebars
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor