CVE-2026-33938

What it actually does

Handlebars versions 4.0.0 through 4.7.8 incorrectly expose the `@partial-block` special variable through the template data context in a way that allows it to be modified by helpers that accept or write arbitrary objects. If an attacker can influence template content, helper inputs, or data passed into templates, they may cause a helper to replace `@partial-block` with a crafted Handlebars abstract syntax tree (AST). When the application later invokes `{{> @partial-block}}`, vulnerable Handlebars versions may compile and execute that attacker-controlled AST. In server-side Node.js use, this can lead to arbitrary JavaScript execution in the application process, with the privileges of the running service.

Why it matters to the business

Successful exploitation can allow an attacker to run code inside a server-side application that uses vulnerable Handlebars versions, potentially resulting in data theft, application tampering, service disruption, credential exposure, or pivoting to other systems reachable from the application. The CVSS score is high at 8.1, but exploitation requires a specific application pattern: attacker influence over templates or template data plus helpers capable of mutating context objects. EPSS is currently low and there is no known CISA KEV listing or ransomware association, but Handlebars is widely used in JavaScript applications and transitive dependencies may hide exposure in larger software supply chains.

How an attack unfolds

An attacker first identifies an application that performs server-side Handlebars rendering with a vulnerable `handlebars` package version from 4.0.0 through 4.7.8. The attacker then looks for a path where they can influence template source, partial content, template data, or inputs consumed by registered helpers. If the application registers helpers that can write arbitrary values into provided objects, including helpers from broad third-party helper libraries, the attacker abuses that behavior to overwrite the `@partial-block` entry in the template data context. The overwritten value is shaped as a Handlebars AST that represents attacker-controlled JavaScript execution. When application rendering later reaches a dynamic partial invocation such as `{{> @partial-block}}`, vulnerable Handlebars compiles and executes the attacker-controlled AST. The resulting code executes in the Node.js process, enabling access to application secrets, files, network resources, and any operations permitted by the service account.

How to fix it

Upgrade Handlebars to version 4.7.9 or later wherever the full compiler build is used. Because this package is often introduced transitively, review lockfiles and dependency trees, not only direct package manifests. If immediate upgrade is not possible, use the runtime-only build via `require('handlebars/runtime')` in production paths so `compile()` is absent and the vulnerable fallback compilation path is unavailable. Audit all registered helpers, especially helpers from third-party packages such as `handlebars-helpers`, and remove or rewrite any helper that writes arbitrary values to context objects or treats template data as mutable. Do not allow untrusted users to submit or modify server-side Handlebars templates, partials, helper names, or data structures that helpers can mutate. Treat template data passed into helpers as read-only, and isolate rendering processes where possible with least-privilege service accounts and restricted filesystem/network access.

How to confirm the fix worked

Confirm all deployed applications resolve `handlebars` to version 4.7.9 or later by checking package manifests, lockfiles, software composition analysis results, container images, and built artifacts. Use `npm ls handlebars`, `yarn why handlebars`, `pnpm why handlebars`, or equivalent tooling to identify direct and transitive installations. Verify production server-side code does not call `require('handlebars')` with vulnerable versions or expose `Handlebars.compile()` to untrusted template content; prefer `require('handlebars/runtime')` where templates are precompiled. Review registered helpers for assignments into context or data objects, especially generic helpers that accept object paths or arbitrary keys. Regression-test rendering flows that use partial blocks to ensure legitimate templates still render after upgrade or helper hardening. If feasible, add unit tests asserting that helpers cannot mutate `@partial-block` or other internal data-frame properties.

Typical attack path

1. Fingerprint a target application or dependency tree to determine whether server-side Handlebars 4.0.0 through 4.7.8 is in use.
2. Find an input path that influences templates, partials, template data, or helper arguments used during server-side rendering.
3. Identify registered helpers that mutate arbitrary objects or expose write-like behavior against the template data context.
4. Use the helper behavior to overwrite `@partial-block` with a crafted Handlebars AST rather than a legitimate partial block.
5. Trigger rendering that invokes `{{> @partial-block}}`.
6. Achieve arbitrary JavaScript execution in the server-side Node.js process.
7. Use the process privileges to read sensitive data, alter application behavior, create persistence, or pivot to other reachable services.

How to detect it

To determine whether exploitation already occurred, review dependency and application context first: exploitation is only plausible where vulnerable Handlebars versions are used server-side with runtime compilation and mutable helpers. Examine application logs around template rendering endpoints for unusual partial-block behavior, template compilation failures, AST parsing errors, or helper errors involving unexpected object writes. Review web access logs for requests that submit or modify template content, partials, themes, email templates, CMS layouts, report templates, or other server-rendered user-customizable content. Correlate those requests with Node.js process telemetry showing unexpected child processes, shell execution, filesystem access outside normal application paths, environment variable reads, credential file access, or unusual outbound network connections. Inspect application code and logs for use of third-party helper libraries and helpers that accept arbitrary object paths or keys. On hosts and containers, review process creation events where the parent is a Node.js application process and the child is a shell, scripting engine, network utility, or system discovery command. If EDR or audit logs are available, search for Node.js processes reading secrets, cloud metadata endpoints, SSH keys, `.env` files, package manager tokens, or service account credentials shortly after suspicious rendering requests. There are no universal network indicators because payloads are application-specific; detection should focus on vulnerable library presence, dangerous rendering patterns, and post-exploitation behavior from the Node.js process.

• handlebars@4.0.0
• handlebars@4.0.1
• handlebars@4.0.2
• handlebars@4.0.3
• handlebars@4.0.4
• handlebars@4.0.5
• handlebars@4.0.6
• handlebars@4.0.7
• handlebars@4.0.8
• handlebars@4.0.9
• handlebars@4.0.10
• handlebars@4.0.11
• handlebars@4.0.12
• handlebars@4.0.13
• handlebars@4.0.14
• handlebars@4.1.0
• handlebars@4.1.1
• handlebars@4.1.2
• handlebars@4.2.0
• handlebars@4.2.1
• handlebars@4.3.0
• handlebars@4.4.0
• handlebars@4.4.1
• handlebars@4.4.2
• handlebars@4.4.3
• handlebars@4.4.4
• handlebars@4.4.5
• handlebars@4.5.0
• handlebars@4.5.1
• handlebars@4.5.2
• handlebars@4.5.3
• handlebars@4.6.0
• handlebars@4.7.0
• handlebars@4.7.1
• handlebars@4.7.2
• handlebars@4.7.3
• handlebars@4.7.4
• handlebars@4.7.5
• handlebars@4.7.6
• handlebars@4.7.7
• handlebars@4.7.8
• {{> @partial-block}}
• @partial-block
• Handlebars.compile
• handlebars.compile
• require('handlebars')
• require("handlebars")
• require('handlebars/runtime')
• require("handlebars/runtime")
• handlebars-helpers
• node_modules/handlebars/package.json
• node_modules/handlebars/dist/cjs/handlebars/compiler/compiler.js
• node_modules/handlebars/lib/handlebars/compiler/compiler.js

What your security team should do

• Prioritize inventory of all applications, services, build artifacts, and containers that include `handlebars` versions 4.0.0 through 4.7.8.
• Upgrade vulnerable deployments to Handlebars 4.7.9 or later, including transitive dependencies pinned in lockfiles.
• Where templates are not compiled at runtime, switch production server-side rendering to the runtime-only build using `require('handlebars/runtime')`.
• Audit and restrict registered helpers; remove helpers that mutate arbitrary objects or come from broad third-party helper collections in untrusted rendering contexts.
• Search code for dynamic partial block usage and runtime compilation paths, especially `{{> @partial-block}}`, `Handlebars.compile`, and `handlebars.compile`.
• Block or tightly validate any user-controlled template, partial, or helper input until patching and helper review are complete.
• Review application and host telemetry for suspicious template rendering errors, unexpected Node.js child processes, file reads, outbound network connections, or secret access from rendering services.
• Run software composition analysis in CI/CD to prevent reintroduction of vulnerable Handlebars versions.