REDHAT-BUG-2452508: High severity Handlebars Handlebars vulnerability

Q: Which applications are exposed to this denial-of-service condition?

Applications using Handlebars versions 4.0.0 through 4.7.8 are exposed when they compile user-supplied templates and do not handle compilation or rendering errors with try/catch. A single crafted template using an unregistered decorator can crash the Node.js process.

Q: What must an attacker provide to trigger the crash?

The attacker needs a way to submit a template that the application passes to Handlebars compile(). The template must contain decorator syntax referring to an unregistered decorator, such as {{*n}}.

Q: How can this be mitigated if an upgrade is not immediately possible?

Wrap template compilation and rendering in try/catch to prevent the unhandled error from terminating the process. Also reject user templates containing {{*...}} syntax when decorators are not used, or pre-compile templates during the build process and avoid calling compile() for request-time input.

Q: How can an organization determine whether it is affected?

Check whether the application uses Handlebars 4.0.0 through 4.7.8 and accepts templates from users or other untrusted sources. It is affected when those templates are compiled at request time without error handling and can include unregistered decorator syntax.

Published Mar 27, 2026

Updated

Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, 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. Version 4.7.9 fixes the issue. Some workarounds are available. Wrap compilation and rendering in try/catch. 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 Software

2 affected components

Handlebars Handlebars>=4.0.0<=4.7.8

Handlebars Handlebars=4.7.9

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Handlebars to a version that resolves this vulnerability.
Fixed in 4.7.9
Configuration
Use the pre-compilation workflow: compile templates at build time and serve only pre-compiled templates; do not call `compile()` at request time.
Handlebars template compilation workflow request-time template compilation (compile()) = disabled
Configuration
Validate template input before passing it to `compile()`; reject templates containing decorator syntax (`{{*...}}`) if decorators are not used in your application.
Handlebars template input validation decorator syntax allowance = reject `{{*...}}` when decorators are not used
Configuration
Wrap compilation and rendering in `try/catch` to prevent unhandled `TypeError: ... is not a function` from crashing the Node.js process.
Node.js runtime handling of Handlebars compilation/rendering error handling for compilation and rendering = wrap in try/catch

Event History

Mar 27, 2026

Data Sourced

via Red Hat·10:02 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which applications are exposed to this denial-of-service condition?

Applications using Handlebars versions 4.0.0 through 4.7.8 are exposed when they compile user-supplied templates and do not handle compilation or rendering errors with try/catch. A single crafted template using an unregistered decorator can crash the Node.js process.

What must an attacker provide to trigger the crash?

The attacker needs a way to submit a template that the application passes to Handlebars compile(). The template must contain decorator syntax referring to an unregistered decorator, such as {{*n}}.

How can this be mitigated if an upgrade is not immediately possible?

Wrap template compilation and rendering in try/catch to prevent the unhandled error from terminating the process. Also reject user templates containing {{*...}} syntax when decorators are not used, or pre-compile templates during the build process and avoid calling compile() for request-time input.

How can an organization determine whether it is affected?

Check whether the application uses Handlebars 4.0.0 through 4.7.8 and accepts templates from users or other untrusted sources. It is affected when those templates are compiled at request time without error handling and can include unregistered decorator syntax.

REDHAT-BUG-2452508: High severity Handlebars Handlebars vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which applications are exposed to this denial-of-service condition?

What must an attacker provide to trigger the crash?

How can this be mitigated if an upgrade is not immediately possible?

How can an organization determine whether it is affected?

Company

Resources

Contact

Frequently Asked Questions

Which applications are exposed to this denial-of-service condition?

What must an attacker provide to trigger the crash?

How can this be mitigated if an upgrade is not immediately possible?

How can an organization determine whether it is affected?