CVE-2026-33938: Handlebars.js has JavaScript Injection via AST Type Confusion by tampering @partial-block
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, the `@partial-block` special variable is stored in the template data context and is reachable and mutable from within a template via helpers that accept arbitrary objects. When a helper overwrites `@partial-block` with a crafted Handlebars AST, a subsequent invocation of `{{> @partial-block}}` compiles and executes that AST, enabling arbitrary JavaScript execution on the server. Version 4.7.9 fixes the issue. Some workarounds are available. First, use the runtime-only build (`require('handlebars/runtime')`). The `compile()` method is absent, eliminating the vulnerable fallback path. Second, audit registered helpers for any that write arbitrary values to context objects. Helpers should treat context data as read-only. Third, avoid registering helpers from third-party packages (such as `handlebars-helpers`) in contexts where templates or context data can be influenced by untrusted input.
Security readout for executives and security teams
Plain-English summary
Handlebars.js versions 4.0.0 through 4.7.8 can let a malicious template path turn server-side template rendering into JavaScript execution. The main business risk is compromise of systems that render attacker-influenced templates or data with unsafe helpers.
Executive priority
Prioritize remediation for internet-facing or multi-tenant services that render Handlebars templates. The severity is high because successful exploitation can execute server-side JavaScript, but the published scoring notes high attack complexity.
Technical view
The issue is AST type confusion around the mutable `@partial-block` template data value. If a helper writes a crafted Handlebars AST into that value, `{{> @partial-block}}` may compile and execute it. The fixed version is 4.7.9. CVSS is 8.1 high with high attack complexity.
Likely exposure
Exposure is most likely in Node.js or server-side applications using Handlebars.js 4.0.0 through 4.7.8 where templates, context data, or registered helpers can be influenced by untrusted input. Risk is higher when the full compiler is available rather than the runtime-only build.
Exploitation context
The source bundle does not show KEV listing or cited active exploitation. Exploitation appears conditional: an attacker needs a reachable rendering path, influence over template behavior or data, and a helper capable of overwriting arbitrary context values.
Researcher notes
Focus review on helper registration, data-frame mutation, and any code path invoking partial blocks after helper execution. The public description names CWE-843, CWE-917, and CWE-94. Do not assume exploitability without confirming attacker control over template data and helper behavior.
Mitigation direction
Upgrade Handlebars.js to version 4.7.9 or later.
Use `handlebars/runtime` where compilation is not required.
Audit helpers that write arbitrary values into context objects.
Treat template context data as read-only inside helpers.
Avoid third-party helpers in untrusted template or data paths.
Check vendor advisories for packaged platform fixes.
Validation and detection
Search lockfiles and SBOMs for Handlebars.js versions below 4.7.9.
Identify server-side rendering paths using Handlebars compilation.
Review registered helpers for context mutation behavior.
Confirm whether untrusted users influence templates or context data.
Verify patched Red Hat packages where applicable.
Regression-test template rendering after upgrade or runtime-only changes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-843: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Code execution and unsafe deserialization weaknesses often justify reviewing execution behavior and process telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
9Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-843 · source CWE mapping
Access of Resource Using Incompatible Type ('Type Confusion')
Access of Resource Using Incompatible Type ('Type Confusion') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Improper Control of Generation of Code ('Code Injection')
Improper Control of Generation of Code ('Code Injection') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.