CVE-2026-33939

What it actually does

Handlebars 4.0.0 through 4.7.8 can crash a Node.js process when compiling or rendering a template that uses decorator syntax referencing an unregistered decorator, such as `{{*n}}`. The compiled template attempts to resolve the decorator with `lookupProperty(decorators, "n")`, receives `undefined`, and then invokes that value as a function, producing an unhandled `TypeError`. If the application accepts user-supplied templates and does not wrap compilation/rendering in error handling, a single malformed template can terminate the process and cause denial of service. Confidentiality and integrity are not directly affected; the impact is service availability.

Why it matters to the business

Applications that allow users, integrations, or content workflows to submit Handlebars templates may be taken offline by a single crafted request if they compile templates at runtime. This can cause application outages, failed transactions, degraded customer-facing services, and operational disruption. Although EPSS is currently low and the vulnerability is not in the CISA KEV catalog, the low attack complexity and unauthenticated network attack vector make exposed template-compilation paths important to review and patch.

How an attack unfolds

An attacker first identifies an application feature that accepts Handlebars template content or stores user-controlled text that is later passed to `Handlebars.compile()` or rendered dynamically. The attacker submits a template containing decorator syntax for a decorator name that the application has not registered, for example a `{{*...}}` construct. In vulnerable Handlebars versions, compilation or rendering produces code that looks up the decorator, receives `undefined`, and immediately attempts to call it. If the surrounding application does not catch the exception, Node.js treats the resulting `TypeError` as unhandled and the process can terminate. The attacker can repeat the request to keep the service unavailable, especially in deployments where the process manager restarts the application after crashes.

How to fix it

Upgrade Handlebars to version 4.7.9 or later wherever it is used. If immediate upgrade is not possible, wrap all Handlebars compilation and rendering paths in `try/catch` blocks and return controlled errors instead of allowing exceptions to terminate the process. Validate or sanitize user-supplied templates before passing them to `compile()` and reject decorator syntax such as `{{*...}}` if decorators are not intentionally supported. Prefer precompiling trusted templates at build time and serving only precompiled templates in production; avoid calling `Handlebars.compile()` on request-time user input. Review transitive dependencies that bundle or pin Handlebars and ensure package lockfiles are updated so vulnerable 4.0.0 through 4.7.8 versions are not retained.

How to confirm the fix worked

Confirm the installed Handlebars version is 4.7.9 or later using package manager inventory, lockfiles, container image scans, and runtime dependency inspection. Search application code for request-time calls to `Handlebars.compile()`, `handlebars.compile()`, or dynamic template rendering paths that accept user-controlled input. Verify that compilation and rendering are protected by exception handling and that malformed templates return a controlled 4xx/validation error rather than crashing the Node.js process. In a safe non-production environment, test representative template-submission endpoints with decorator syntax such as `{{*n}}` and confirm the service remains running. Also verify monitoring shows no process exits, container restarts, or uncaught exception events during the test.

Typical attack path

1. Find an internet-exposed or API-accessible feature that accepts user-controlled Handlebars templates or template-like content.
2. Submit a template containing unregistered decorator syntax, such as `{{*n}}`.
3. Trigger server-side template compilation or rendering using a vulnerable Handlebars version from 4.0.0 through 4.7.8.
4. Cause the runtime to call an undefined decorator value, resulting in an unhandled `TypeError`.
5. Crash the Node.js process if compilation/rendering is not protected by exception handling.
6. Repeat requests as needed to sustain denial of service.

How to detect it

Review application, API gateway, web server, process manager, container, and Node.js runtime logs for requests containing Handlebars decorator syntax, especially `{{*`, followed by uncaught exceptions or process restarts. Useful sources include application logs, reverse proxy access logs, WAF logs, APM traces, Kubernetes events, container runtime logs, systemd or PM2 logs, and crash reports. Look for `TypeError` messages indicating that a value is not a function near Handlebars compilation or rendering stack traces. Correlate suspicious requests with service restarts, pod restarts, elevated 5xx responses, health-check failures, or abrupt Node.js process exits. Because this issue causes denial of service rather than persistence or code execution, evidence is most likely to appear as malformed template input, uncaught exception stack traces, and restart artifacts rather than files or long-lived host indicators.

• {{*
• TypeError: decorators
• TypeError: decorator
• is not a function
• lookupProperty(decorators
• Handlebars.compile
• handlebars.compile
• uncaughtException
• UnhandledPromiseRejectionWarning
• node:internal/process
• PM2 log: App [
• exited with code
• Kubernetes Back-off restarting failed container
• CrashLoopBackOff
• Error: process exited
• SIGTERM
• SIGABRT

What your security team should do

• Inventory all applications and services using Handlebars, including transitive dependencies and container images.
• Prioritize internet-facing services and any workflows that compile user-supplied templates at runtime.
• Upgrade Handlebars to 4.7.9 or later and refresh lockfiles to remove vulnerable 4.0.0 through 4.7.8 versions.
• Add input validation to reject `{{*...}}` decorator syntax unless decorators are explicitly required and safely registered.
• Ensure all template compilation and rendering code paths use controlled error handling and cannot crash the Node.js process.
• Prefer build-time template precompilation over runtime compilation of user-supplied templates.
• Add monitoring and alerting for uncaught Node.js exceptions, process exits, container restarts, and repeated malformed template submissions.
• Review historical logs for crashes or errors containing decorator syntax and `TypeError` messages consistent with this issue.