CVE-2026-49459

Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It is due to an incomplete fix for a previous issue. This vulnerability can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

Recommendation

Upgrade to version 3.0.8, 4.5.3 or later.

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(root, { IN_PLACE: true }) could preserve event-handler attributes on an attacker-controlled <form> root when a descendant name clobbered properties checked by _isClobbered, because _forceRemove no-opped on the parent-less root and _sanitizeAttributes returned early. This issue is fixed in version 3.4.6.

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(root, { IN_PLACE: true }) could preserve event-handler attributes on an attacker-controlled <form> root when a descendant name clobbered properties checked by _isClobbered, because _forceRemove no-opped on the parent-less root and _sanitizeAttributes returned early. This issue is fixed in version 3.4.6.

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(root, { IN_PLACE: true }) could preserve event-handler attributes on an attacker-controlled <form> root when a descendant name clobbered properties checked by _isClobbered, because _forceRemove no-opped on the parent-less root and _sanitizeAttributes returned early. This issue is fixed in version 3.4.6.

Versions of handlebars prior to 3.0.8 or 4.5.2 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

The following template can be used to demonstrate the vulnerability:

	{{#with split as |a|}}
		{{pop (push "alert('Vulnerable Handlebars JS');")}}
		{{#with (concat (lookup join (slice 0 1)))}}
			{{#each (slice 2 3)}}
				{{#with (apply 0 a)}}
					{{.}}
				{{/with}}
			{{/each}}
		{{/with}}
	{{/with}}
{{/with}}```


## Recommendation

Upgrade to version 3.0.8, 4.5.2 or later.

Versions of handlebars prior to 4.0.14 are vulnerable to Prototype Pollution. Templates may alter an Objects' prototype, thus allowing an attacker to execute arbitrary code on the server.

Recommendation

For handlebars 4.1.x upgrade to 4.1.2 or later. For handlebars 4.0.x upgrade to 4.0.14 or later.

IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM

CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — silent no-op when _forceRemove is called on a parent-less node)

Summary

When DOMPurify.sanitize(root, { IN_PLACE: true }) is called and root is a <form> whose own attributes carry an event handler (onmouseover, onfocus, onclick, etc.), a single descendant element with a name= attribute matching any of the property names _isClobbered checks (nodeName, setAttribute, namespaceURI, insertBefore, hasChildNodes, childNodes) is sufficient to bypass attribute sanitization on the root. _forceRemove silently no-ops because the root has no parent; the iterator drives on to _sanitizeAttributes, which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live.

This affects current main at 89da34e (the just-landed DOM-clobbering hardening fix at 89da34e addressed _sanitizeAttachedShadowRoots walk traversal, not the main _sanitizeElements / _sanitizeAttributes pipeline against the iterator-root node).

Affected

• DOMPurify ≤ 3.4.5, including main at 89da34e03ec17868e561f87f3747a9371b61a9e7
• Any caller that does DOMPurify.sanitize(node, { IN_PLACE: true }) where node is built from untrusted HTML (e.g., parsed via createElement('template').innerHTML = dirty then template.content.firstElementChild handed in)

Not affected:

• String-input DOMPurify.sanitize(dirtyString) — the library builds the DOM itself inside _initDocument, the root is the cleanly-created document body, and clobber-named children of the body cannot shadow body named properties (HTMLBodyElement does not carry [LegacyOverrideBuiltIns])
• IN_PLACE where the root is not an HTMLFormElement
• IN_PLACE where the attacker cannot place a clobber-named child inside the root

Vulnerability details

Code paths

[A] — _forceRemove at src/purify.ts:930-939:

const _forceRemove = function (node: Node): void {
  arrayPush(DOMPurify.removed, { element: node });
  try {
    // eslint-disable-next-line unicorn/prefer-dom-node-remove
    getParentNode(node).removeChild(node);   // [A1] throws when getParentNode returns null
  } catch (_) {
    remove(node);                             // [A2] WebIDL Node.remove() — spec-defined no-op
  }                                           //      when the node has no parent
};

When the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node), getParentNode(node) returns null, null.removeChild(node) throws, the catch falls to remove(node) — which per WebIDL is Element.prototype.remove.call(node), and per spec does nothing if the node has no parent. Nothing about _forceRemove's contract acknowledges this — the function appears to its callers as "the node is gone now," but the node is still in place.

[B] — _sanitizeAttributes at src/purify.ts:1490-1492:

const _sanitizeAttributes = function (currentNode: Element): void {
  _executeHooks(hooks.beforeSanitizeAttributes, currentNode, null);

  const { attributes } = currentNode;

  /* Check if we have attributes; if not we might have a text node */
  if (!attributes || _isClobbered(currentNode)) {
    return;                                   // [B] silently skips ALL attribute checks
  }                                           //     for clobbered nodes
  ...
};

The skip at [B] is deliberate — the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is "if _isClobbered, then _sanitizeElements already removed this node, so we will never reach _sanitizeAttributes on it." That invariant holds for every non-root node…

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(root, { IN_PLACE: true }) could preserve event-handler attributes on an attacker-controlled <form> root when a descendant name clobbered properties checked by _isClobbered, because _forceRemove no-opped on the parent-less root and _sanitizeAttributes returned early. This issue is fixed in version 3.4.6.

TuxCare rebuilt handlebars to address 1 CVE. Fixed in 1.3.0-tuxcare.1.

TuxCare rebuilt handlebars to address 3 CVEs. Fixed in 1.0.12-tuxcare.2.

TuxCare rebuilt dompurify to address 5 CVEs. Fixed in 3.1.6-tuxcare.4.

TuxCare rebuilt dompurify to address 8 CVEs. Fixed in 3.2.3-tuxcare.2.

TuxCare rebuilt dompurify to address 14 CVEs. Fixed in 2.4.7-tuxcare.1.

TuxCare rebuilt dompurify to address 34 CVEs. Fixed in 3.0.3-tuxcare.1.

TuxCare rebuilt dompurify to address 3 CVEs. Fixed in 3.2.7-tuxcare.2.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 2.3.0-tuxcare.5.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 3.0.3-tuxcare.5.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 2.4.7-tuxcare.5.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 2.4.3-tuxcare.8.

TuxCare rebuilt dompurify to address 8 CVEs. Fixed in 2.5.8-tuxcare.7.

TuxCare rebuilt dompurify to address 9 CVEs. Fixed in 3.4.5-tuxcare.2.

TuxCare rebuilt dompurify to address 6 CVEs. Fixed in 2.0.8-tuxcare.2.

TuxCare rebuilt dompurify to address 5 CVEs. Fixed in 3.3.3-tuxcare.2.

TuxCare rebuilt dompurify to address 10 CVEs. Fixed in 3.2.6-tuxcare.2.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 2.3.3-tuxcare.3.

TuxCare rebuilt dompurify to address 2 CVEs. Fixed in 2.4.0-tuxcare.8.

TuxCare rebuilt dompurify to address 7 CVEs. Fixed in 3.0.6-tuxcare.5.

TuxCare rebuilt dompurify to address 12 CVEs. Fixed in 3.4.0-tuxcare.1.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 3.0.5-tuxcare.4.

TuxCare rebuilt dompurify to address 11 CVEs. Fixed in 3.0.4-tuxcare.4.

Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to prototype pollution. It is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions.

Recommendation

Upgrade to version 3.0.8, 4.5.3 or later.

Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to Arbitrary Code Execution. The package's lookup helper fails to properly validate templates, allowing attackers to submit templates that execute arbitrary JavaScript in the system. It is due to an incomplete fix for a previous issue. This vulnerability can be used to run arbitrary code in a server processing Handlebars templates or on a victim's browser (effectively serving as Cross-Site Scripting).

Recommendation

Upgrade to version 3.0.8, 4.5.3 or later.

Root has patched CVE-2026-49459 in the dompurify package for Root:npm. Multiple fixed versions available.

Root has patched GHSA-2cf5-4w76-r9qv in the handlebars package for Root:npm. Multiple fixed versions available.

Root has patched GHSA-g9r4-xpmj-mj65 in the handlebars package for Root:npm. Multiple fixed versions available.

Root has patched GHSA-q2c6-c6pm-g3gh in the handlebars package for Root:npm. Multiple fixed versions available.

Root has patched GHSA-q42p-pg8m-cqh6 in the handlebars package for Root:npm. Multiple fixed versions available.