NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

CVE-2026-33939 — handlebars

HIGHFix: handlebars-lang/handlebars.js@68d8df5

CVE-2026-33939 is a high-severity (CVSS 7.5) CWE-754 vulnerability in handlebars. A fix is available for handlebars — see the affected versions and patch details below.

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

Also known asGHSA-9cx6-37pm-9jff
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33939.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs50th percentile — riskier than 50% of all scored CVEsHighest risk
0.00%0.42%0.84%1.26%0.1%0.6%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

17Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
handlebarsnpm
57.1Mdownloads / week

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 Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmhandlebars≥ 4.0.0&&< 4.7.94.7.9npm install handlebars@4.7.9

Affected Products

1 product · 1 configurations
Application
handlebarshandlebarsjs
≥ 4.0.0 && < 4.7.9
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for handlebars, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update handlebars to 4.7.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33939 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This is an Important denial of service flaw in Handlebars.js affecting applications that compile user-supplied templates without proper error handling. A remote attacker can submit a malformed template containing unregistered decorator syntax, leading to an unhandled `TypeError` and crashing the Node.js process. Red…

Workaround published by Red Hat
To mitigate this issue, applications utilizing Handlebars.js should implement robust error handling during template compilation and rendering. Specifically, wrap template compilation and rendering calls in `try/catch` blocks to gracefully handle `TypeError` exceptions. Alternatively, validate user-supplied template input to reject decorator syntax (`{{*...}}`) if decorators are not actively used by the application. Employing a pre-compilation workflow, where templates are compiled at build time and only pre-compiled templates are served, can also prevent runtime exploitation. If the application is a service, a restart may be required for changes to take effect.
Source: Red Hat security advisory for CVE-2026-33939 (CC BY 4.0)
ProductFixed inAdvisory
Cluster Observability Operator 1.5.3cluster-observability-operator/logging-console-plugin-pf4-rhel9:1782839279RHSA-2026:34342
Red Hat OpenShift Dev Spaces 3.27devspaces/code-rhel9:1776744110RHSA-2026:10175

Frequently Asked Questions

## 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 generate
O3 Security · Impact-Aware SCA

Is CVE-2026-33939 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-33939: handlebars DoS — Fixed in 4.7.9