hbs is an Express view engine wrapper for Handlebars.

CVE-2026-87123 affects only hbs 4.3.0, the Express.js view engine wrapper for Handlebars. When an async helper registered with registerAsyncHelper resolves to an object whose toHTML property is truthy but not callable, escapeExpression throws a TypeError. Because the async substitution runs on a later tick — outside the render function's try/catch — the exception is uncaught and kills the Node.js process outright. The flaw was introduced as a side effect of the fix for CVE-2026-16231 and does not exist in earlier or later versions. Exploitation requires the attacker to influence the shape of the object returned by an async helper (e.g., by injecting a JSON payload with a toHTML key), so the attack surface is narrow: the app must use registerAsyncHelper AND feed externally controlled data into that helper's return value.

The vendor's MEDIUM / 5.9 rating is generous for this bug. The CVSS vector's AC:H already acknowledges the conditional nature, but even that understates the real-world friction. The affected version window is exactly one patch release (4.3.0), meaning most teams either never picked it up or have already moved to 4.3.1. The impact ceiling is availability-only (no confidentiality or integrity loss), and virtually every production Node.js deployment uses a process manager (PM2, systemd, Docker restart policy, Kubernetes liveness probes) that auto-restarts the crashed process in seconds. This is a nuisance, not a breach.

Why this verdict

• Single-version regression: Only hbs 4.3.0 is vulnerable — a short-lived patch release. The exposed population is a small slice of the ~200–300K weekly download base; most installs are on 4.2.x or already on 4.3.1.
• AC:H is understated friction: The attacker must find an app that (a) uses the niche registerAsyncHelper API and (b) feeds attacker-controlled objects into the helper's return path. This is application-specific and not generically exploitable.
• Availability-only, self-healing impact: The worst outcome is a Node.js process crash. PM2, systemd, Docker restart policies, and Kubernetes liveness probes restart the process in seconds. Sustained DoS requires continuous request flooding, which is detectable and blockable.
• Role multiplier: hbs is a view-rendering library for Express.js web applications. It is NOT deployed as an identity provider, domain controller, hypervisor, backup agent, CI/CD component, or any other high-value-role software. Its blast radius is limited to one Express process on one application host — no lateral movement, no privilege escalation, no fleet-scale impact. No high-value-role floor applies.

Why not higher?

The vendor's MEDIUM/5.9 already accounts for AC:H, but it does not adequately penalize the single-version scope and the self-healing nature of Node.js process crashes in production. There is no confidentiality or integrity impact, no privilege escalation path, no PoC in the wild, and the EPSS is bottom-quintile. The component occupies no high-value infrastructure role that would trigger a blast-radius floor.

Why not lower?

Despite all the friction, the bug IS remotely triggerable without authentication. An application that does use registerAsyncHelper with untrusted input would be reliably crashable, and not every deployment has robust process-manager auto-restart configured. A full IGNORE verdict would be inappropriate because a subset of deployments could experience genuine service disruption.

1. Upgrade hbs to 4.3.1 immediately — This is a one-line npm update hbs — the simplest possible fix. Given the LOW severity, there is no separate noisgate mitigation SLA; go straight to remediation. The patch is a minimal diff with no breaking changes.
2. Add a global uncaughtException handler — Add process.on('uncaughtException', (err) => { log(err); }) to prevent process termination from unhandled TypeErrors. This is a general resilience measure, not a substitute for patching.
3. Validate async helper return types — Ensure any registerAsyncHelper callback returns only primitive strings or SafeString instances, never raw objects from untrusted sources like parsed JSON.
4. Enable process manager auto-restart — Confirm PM2, systemd, Docker, or Kubernetes is configured to auto-restart the Node.js process on crash. This limits any DoS to a few-second blip per crash event.

Run this on the application host or in your CI pipeline where the project's node_modules is available. No special privileges required. Example: bash check_cve_2026_87123.sh /path/to/your/express-app

#!/usr/bin/env bash
# check_cve_2026_87123.sh — Detect hbs 4.3.0 (CVE-2026-87123)
# Usage: bash check_cve_2026_87123.sh [/path/to/project]
# Exit codes: 0 = PATCHED/NOT_AFFECTED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
PKG_JSON="$PROJECT_DIR/node_modules/hbs/package.json"

if [ ! -f "$PKG_JSON" ]; then
  echo "UNKNOWN — hbs not found in $PROJECT_DIR/node_modules"
  exit 2
fi

VERSION=$(node -e "console.log(require('$PKG_JSON').version)" 2>/dev/null)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse hbs version"
  exit 2
fi

echo "Detected hbs version: $VERSION"

if [ "$VERSION" = "4.3.0" ]; then
  echo "VULNERABLE — hbs 4.3.0 is affected by CVE-2026-87123"
  echo "Upgrade to hbs 4.3.1 or later: npm install hbs@latest"
  exit 1
else
  echo "PATCHED — hbs $VERSION is not affected"
  exit 0
fi

Sources

1. OpenCVE — CVE-2026-87123
2. Shenlong CVE Platform — hbs 4.3.0 Async Helper Escape DoS
3. THREATINT — CVE-2026-87123
4. TheHackerWire — CVE-2026-87123
5. npm — hbs package
6. Snyk — hbs vulnerabilities
7. GitHub — pillarjs/hbs