CVE-2026-87123 in hbs
Summary
by MITRE • 09/11/2026
hbs is an Express view engine wrapper for Handlebars. Version 4.3.0 can crash the Node.js process during output escaping when an async helper, registered with registerAsyncHelper, resolves to an object whose toHTML property is truthy but not callable. Handlebars escapeExpression calls the toHTML method on any value that has a truthy toHTML, so such a value throws a TypeError, and because the async substitution runs on a later tick outside the render function's try/catch, the throw is an uncaught exception that terminates the process without sending a response. Only version 4.3.0 is affected, since the throwing escape was introduced by the fix for CVE-2026-16231 and earlier versions do not escape async helper values. It can be triggered remotely when an async helper resolves to an externally influenced object such as parsed JSON. The issue is fixed in hbs 4.3.1, and users should upgrade to hbs 4.3.1 or later.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in the hbs package, specifically affecting version 4.3.0 of this Express view engine wrapper for Handlebars, represents a critical reliability issue stemming from improper error handling within asynchronous helper execution contexts. This flaw allows an attacker to cause a denial of service by crashing the Node.js process through carefully crafted input that exploits the interaction between async helpers and the template rendering engine's output escaping mechanisms. The root cause lies in how hbs 4.3.0 handles values returned from asynchronous custom helpers registered via registerAsyncHelper when those values possess specific object properties related to HTML serialization.
The technical flaw originates from a change introduced as part of the fix for CVE-2026-16231, which aimed to improve security by ensuring that output escaping is applied consistently to async helper results. In this implementation, Handlebars escapeExpression checks if a value has a truthy toHTML property and attempts to invoke it as a method. However, in version 4.3.0, there was no validation to ensure that the toHTML property is actually callable before invocation. When an asynchronous helper resolves to an object where toHTML exists but is not a function, such as a plain string or number assigned to that key, the escapeExpression call throws a TypeError. Because async helpers execute on a later tick outside the synchronous try/catch block surrounding the initial render operation, this exception becomes uncaught within the context of the request handling cycle.
The operational impact of this vulnerability is severe for any application relying on hbs 4.3.0 to serve dynamic content via HTTP requests. Since the TypeError occurs asynchronously and without a corresponding error handler in the rendering pipeline, it propagates up as an unhandled exception that terminates the Node.js process immediately. This results in a complete denial of service for all users accessing the application until the server is restarted or the process is recovered by external monitoring tools. The vulnerability can be triggered remotely if an attacker controls input data that influences the resolution value of an async helper, such as through parsed JSON payloads submitted via API endpoints or form submissions that are subsequently rendered using Handlebars templates with registered asynchronous helpers.
This incident aligns with CWE-252, Unchecked Return Value, and CWE-754, Improper Check for Unusual or Exceptional Conditions, as the code fails to validate the type of a property before invoking it. Furthermore, from an offensive security perspective, this behavior is consistent with ATT&CK technique T1499, Endpoint Denial of Service, specifically under sub-techniques involving application exhaustion through resource consumption or process termination via unhandled exceptions. The lack of proper exception handling in asynchronous callbacks creates a predictable crash vector that does not require complex exploitation chains, making it an efficient method for disrupting service availability.
The issue was resolved in hbs version 4.3.1 by implementing robust type checking before invoking the toHTML property or ensuring that errors during async helper execution are properly caught and handled within the request lifecycle. To mitigate this vulnerability, organizations using hbs must upgrade immediately to version 4.3.1 or any later release where the asynchronous error handling has been corrected. For applications unable to update promptly due to dependency constraints, temporary mitigations include avoiding the use of async helpers that resolve to objects with mutable properties controlled by user input, or wrapping template rendering logic in global uncaught exception handlers that gracefully shut down requests rather than crashing the entire process, although upgrading remains the only definitive remediation.