CVE-2026-49459

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…

Impact

A DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied TRUSTED_TYPES_POLICY even after clearConfig() is called. A later caller that requests RETURN_TRUSTED_TYPE receives a TrustedHTML object created by the old policy, not by a clean default configuration.

If the old policy is unsafe or controlled by a less-trusted integration, this turns a later "default" sanitize call into script execution at a Trusted Types sink. TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy. dompurify-trusted-types-policy-survives-clearconfig-poc.js

Affected version

Tested against DOMPurify 3.4.8, repository commit 825e617753ac1169306a542d3174a77f717a0cf6.

Root cause

_parseConfig() overwrites trustedTypesPolicy when cfg.TRUSTED_TYPES_POLICY is truthy, but the default/null path only initializes the internal policy when trustedTypesPolicy === undefined. Once a custom policy has been set, later default config parsing leaves it in place.

Relevant code:

• src/purify.ts:786-812 accepts and stores cfg.TRUSTED_TYPES_POLICY.
• src/purify.ts:813-832 does not reset an existing policy when config has no policy or has TRUSTED_TYPES_POLICY: null.
• src/purify.ts:2123-2125 signs the final serialized HTML with the retained policy when RETURN_TRUSTED_TYPE is true.
• src/purify.ts:2133-2136 clearConfig() only clears CONFIG and SET_CONFIG; it does not reset trustedTypesPolicy or emptyHTML.

Local PoC

Run from the DOMPurify checkout, or set DOMPURIFY_REPO:

node /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js

Observed output:

{
  "result": {
    "baseline": "<b>baseline</b>",
    "duringPolicy": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterClearString": "<img src=\"x\">",
    "afterClearTrustedType": "[object TrustedHTML]",
    "afterClearTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterNullTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "mountedHTML": "<img src=\"x\" onerror=\"alert(&quot;TT_POLICY_SURVIVED_CLEARCONFIG&quot;)\">"
  },
  "dialogs": [
    "TT_POLICY_SURVIVED_CLEARCONFIG"
  ]
}

The important part is the split behavior after cleanup:

• purify.clearConfig(); purify.sanitize(...); returns a normal sanitized string (<img src="x">), because the later call is not asking for a Trusted Type.
• purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true }); still uses the old policy and returns attacker-controlled TrustedHTML.
• Passing { TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true } also still returns attacker-controlled TrustedHTML.

Preconditions

This is a shared-instance state contamination issue. It matters when one DOMPurify instance is reused by multiple integrations, plugins, request handlers, or components with different trust levels, and a cleanup step relies on clearConfig() to restore safe defaults.

This is not a default string-input bypass. An attacker must be able to influence a prior TRUSTED_TYPES_POLICY on the reused instance, or a less-trusted integration must have installed an unsafe policy.

Severity

impact is XSS at a Trusted Types sink in applications that reuse a DOMPurify instance across trust boundaries. Attack complexity is high because exploitation depends on prior policy injection or a less-trusted integration and a later RETURN_TRUSTED_TYPE sink.

Suggested fix

Make clearConfig() reset Trusted Types state as part of restoring defaults, or have _parseConfig() explicitly clear trustedTypesPolicy and emptyHTML when TRUSTED_TYPES_POLICY: null is supplied.

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.

Summary

When DOMPurify.sanitize(root, { IN_PLACE: true }) is called on an attacker-supplied live DOM node, DOMPurify still trusts currentNode.nodeName for non-form nodes in the main _sanitizeElements pipeline. A real <script> child node whose observable nodeName is attacker-controlled can therefore be misclassified as an allowed element and retained. When the sanitized tree is inserted into a live document, the script executes.

This affects current 3.4.6. The recent IN_PLACE hardening work covers clobbered form handling and foreign-realm shadow/template traversal, but does not harden the main per-node element decision for hostile non-form live nodes.

Affected

• DOMPurify 3.4.6
• Any caller that does DOMPurify.sanitize(node, { IN_PLACE: true }) on attacker-supplied live DOM nodes
• Verified attacker-controlled node sources:
  • same-origin iframe → live node passed by reference
  • same-origin window.open() popup → live node passed by reference
  • same-origin foreign node adopted into the host document via document.adoptNode(node) and then sanitized in-place

Not affected:

• String-input DOMPurify.sanitize(dirtyString)

Vulnerability details

Code paths

[A] — _sanitizeElements uses the instance-visible nodeName for the allow/forbid decision:

const _sanitizeElements = function (currentNode: any): boolean {
  ...
  if (_isClobbered(currentNode)) {
    _forceRemove(currentNode);
    return true;
  }

  const tagName = transformCaseFunc(currentNode.nodeName);
  ...
  if (
    FORBID_TAGS[tagName] ||
    (!(...) && !ALLOWED_TAGS[tagName])
  ) {
    ...
    _forceRemove(currentNode);
    return true;
  }
  ...
};

For non-form nodes, _isClobbered(currentNode) returns false early. The subsequent element decision therefore trusts currentNode.nodeName directly.

[B] — _isClobbered is form-specific:

const _isClobbered = function (element: Element): boolean {
  const realTagName = getNodeName ? getNodeName(element) : null;
  if (typeof realTagName !== 'string') {
    return false;
  }

  if (transformCaseFunc(realTagName) !== 'form') {
    return false;
  }

  return (...);
};

The hardening is intentionally scoped to form. Non-form nodes are not checked for divergence between the instance-visible property view and the trusted prototype getter view.

Why the bypass works

The attack does not depend on string HTML parsing. It depends on a hostile live DOM object crossing a trust boundary into DOMPurify's IN_PLACE pipeline.

If the attacker controls a same-origin subcontext (iframe or popup), they can prepare a real DOM subtree there and then pass the live node object by reference to a host page that trusts DOMPurify.sanitize(node, { IN_PLACE: true }) as its final sanitization step.

For the verified primitive below:

• the real child node is <script>
• its script text is attacker-controlled
• the observable nodeName is attacker-controlled and made to appear as "DIV"
• _sanitizeElements therefore classifies the real <script> child as an allowed element
• the real <script> survives in the sanitized tree and executes on insertion

This primitive survives:

• direct reference passing
• document.adoptNode(node) followed by IN_PLACE

It does not survive:

• importNode
• cloneNode

because those paths materialize a fresh node and discard the hostile object semantics.

Proof of concept

(1) Minimal — runnable in a single browser context

<!doctype html>
<html><body>
<script src="dist/purify.js"></script>
<script>
  const foreign = window.open('about:blank', '_blank', 'noopener=no');

  const host = foreign.document.createElement('div');
  const script = foreign.document.createElement('script');
  script.textContent = 'window.__pwned = 1';
  Object.defineProperty(script, 'nodeName', {
    value: 'DIV',
    configurable: true,
  });
  host.appendChild(script);

  DOMPurify.sanitize(host, {…

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.

Hook mutation of data.allowedTags / data.allowedAttributes permanently pollutes DEFAULT_ALLOWED_TAGS / DEFAULT_ALLOWED_ATTR

CWE: CWE-501 (Trust Boundary Violation — hook-scoped mutation leaks to global default sets) via CWE-693 (Protection Mechanism Failure — the default allow-list is silently widened for all subsequent sanitize calls)

Summary

The data.allowedTags and data.allowedAttributes fields passed to uponSanitizeElement and uponSanitizeAttribute hooks are direct references to the library's live ALLOWED_TAGS / ALLOWED_ATTR sets. For sanitize calls that don't supply an explicit cfg.ALLOWED_TAGS / cfg.ALLOWED_ATTR array, those live sets are themselves direct references to the module-level DEFAULT_ALLOWED_TAGS / DEFAULT_ALLOWED_ATTR constants. A hook that mutates these fields — a natural-looking pattern for "allow X for this iteration" — permanently writes new entries into the default constants for the DOMPurify instance's lifetime. Every subsequent sanitize call that doesn't override the config inherits the widened defaults, so an attacker payload that uses the poisoned tag/attribute name survives sanitization. removeAllHooks(), clearConfig(), and even passing a fresh cfg: {} do not recover; only constructing a new DOMPurify instance does.

The maintainer's existing defense at src/purify.ts:696-700 explicitly clones DEFAULT_ALLOWED_TAGS before mutating it via cfg.ADD_TAGS (array form), demonstrating awareness of this exact class. The hook path remained uncovered.

Affected

• DOMPurify ≤ 3.4.5, including main at 7996f1dc78eb8b7922388aed75d94a9f8fad9a36
• Any application that installs a hook on uponSanitizeElement or uponSanitizeAttribute that writes to data.allowedTags[...] = true or data.allowedAttributes[...] = true and later sanitizes attacker-influenced content with default config (no explicit cfg.ALLOWED_TAGS / cfg.ALLOWED_ATTR array)

Vulnerability details

[A] — data.allowedTags is a reference to ALLOWED_TAGS

src/purify.ts:1206-1209:

_executeHooks(hooks.uponSanitizeElement, currentNode, {
  tagName,
  allowedTags: ALLOWED_TAGS,         // [A] direct reference; hook mutation
                                      //     mutates the very ALLOWED_TAGS the
                                      //     library checks on the next element
});

src/purify.ts:1494-1500 (the matching attribute hook):

const hookEvent = {
  attrName: '',
  attrValue: '',
  keepAttr: true,
  allowedAttributes: ALLOWED_ATTR,    // [A'] same pattern
  forceKeepAttr: undefined,
};

[B] — ALLOWED_TAGS = DEFAULT_ALLOWED_TAGS for default-cfg sanitize calls

src/purify.ts:527-531:

ALLOWED_TAGS =
  objectHasOwnProperty(cfg, 'ALLOWED_TAGS') &&
  arrayIsArray(cfg.ALLOWED_TAGS)
    ? addToSet({}, cfg.ALLOWED_TAGS, transformCaseFunc)
    : DEFAULT_ALLOWED_TAGS;            // [B] reference assignment; ALLOWED_TAGS
                                       //     IS the DEFAULT_ALLOWED_TAGS object

(The ALLOWED_ATTR = DEFAULT_ALLOWED_ATTR path at :532-536 is symmetric.)

The mismatch

A hook author who writes data.allowedTags['script'] = true reasonably expects per-call scope — the API name is "data", suggesting per-event payload. But [A] makes this a direct reference, and [B] makes that reference equal to the module-level default for the common default-cfg path. The hook's mutation therefore writes to a constant that every subsequent default-cfg sanitize call rebinds to.

The maintainer already recognized this class for the ADD_TAGS array path — src/purify.ts:696-700:

} else if (arrayIsArray(cfg.ADD_TAGS)) {
  if (ALLOWED_TAGS === DEFAULT_ALLOWED_TAGS) {
    ALLOWED_TAGS = clone(ALLOWED_TAGS);   // explicitly clone DEFAULT before
                                          // mutating to avoid this pollution
  }
  addToSet(ALLOWED_TAGS, cfg.ADD_TAGS, transformCaseFunc);
}

The same…

Summary

DOMPurify 3.4.7 shipped a security fix ("permanent hook pollution") that makes a registered uponSanitizeAttribute hook's mutation of data.allowedAttributes non-persistent — so allowing an attribute for one element does not leak into later sanitize() calls. The fix clones ALLOWED_ATTR inside _parseConfig.

That guard is silently bypassed whenever the application uses the persistent-config API DOMPurify.setConfig(). setConfig() sets the module flag SET_CONFIG = true, which causes sanitize() to skip _parseConfig entirely — and the clone-guard lives inside _parseConfig. The hook is then handed the live, shared ALLOWED_ATTR object; any data.allowedAttributes[name] = true it writes mutates that shared object permanently, for the lifetime of the DOMPurify instance, across every subsequent call, and across all elements.

If an application uses setConfig() together with an uponSanitizeAttribute hook that conditionally allows a dangerous attribute (onerror, onclick, onmouseover, srcdoc, formaction, …) for "trusted" elements, then one trusted render permanently allows that attribute on untrusted, attacker-controlled content — yielding stored XSS in viewers' browsers. DOMPurify applies no separate /^on/ event-handler blocklist: attribute stripping is governed entirely by the allowlist, so a polluted allowlist is the only gate, and survival in the output is final.

Affected configuration (preconditions)

The vulnerability is triggered when an application does both:

1. Calls DOMPurify.setConfig(...) once (the recommended pattern for a fixed, persistent policy), and
2. Registers an uponSanitizeAttribute hook that writes data.allowedAttributes[name] = true to conditionally allow an attribute (e.g. only for elements bearing a trust marker).

This hook pattern is demonstrated in DOMPurify's own test suite, and the per-call variant of exactly this leak is what 3.4.7 was released to fix.

Root cause (source: src/purify.ts, v3.4.10)

The 3.4.7 clone-guard — only inside _parseConfig:

// src/purify.ts  _parseConfig()  (lines ~950-968)
// "if a hook is registered AND the set still points at the default constant, clone it.
//  The hook then mutates the clone ... and the next default-cfg call rebinds to the untouched original."
if ( ... && hooks.uponSanitizeAttribute.length > 0) {
  ALLOWED_TAGS = clone(ALLOWED_TAGS);          // line 961
}
if ( ... hooks.uponSanitizeAttribute.length > 0 ... ) {
  ALLOWED_ATTR = clone(ALLOWED_ATTR);          // line 968
}

sanitize() skips _parseConfig on the persistent-config path:

// src/purify.ts  DOMPurify.sanitize()  (line 2369)
if (!SET_CONFIG) {
  _parseConfig(cfg);          // <-- clone-guard lives in here; SKIPPED when SET_CONFIG is true
}

setConfig() sets the flag that disables the guard:

// src/purify.ts  (lines 2596-2598)
DOMPurify.setConfig = function (cfg = {}) {
  _parseConfig(cfg);
  SET_CONFIG = true;          // every later sanitize() now skips _parseConfig
};

The hook is handed the live allowlist binding, and there is no secondary event-handler defense:

// src/purify.ts (line 2088) — hook event exposes the shared object by reference
allowedAttributes: ALLOWED_ATTR,
// (line 2108) hooks.uponSanitizeAttribute executed; a write to data.allowedAttributes mutates ALLOWED_ATTR itself
// _isValidAttribute gates purely on ALLOWED_ATTR[lcName]; DOMPurify uses NO /^on/ blocklist by design.

Net: after setConfig(), the clone-guard never runs, so the hook's allowedAttributes mutation is a permanent write to the instance's shared ALLOWED_ATTR.

Proof of Concept

Environment: npm i [email protected] jsdom (Node; identical mechanism to isomorphic-dompurify, and to a browser instance).

PoC 1 — the leak (trusted render permanently allows onerror on attacker content)

const createDOMPurify =…

Summary

When DOMPurify is configured with both SAFE_FOR_TEMPLATES: true and RETURN_DOM: true (or IN_PLACE: true), an attacker can inject template expressions, such as ${evil}, {{evil}}, or <%evil%>, that survive the sanitization pass inside <template> element content. This bypasses the explicit purpose of SAFE_FOR_TEMPLATES, which is to prevent template engine evaluation of user-supplied content.

Note: The string output path is not affected. Only the DOM return paths (RETURN_DOM: true, RETURN_DOM_FRAGMENT: true, IN_PLACE: true) are vulnerable.

Description

Background

SAFE_FOR_TEMPLATES is designed to strip {{ }}, ${ }, and <% %> expressions from sanitized output so that downstream template engines do not evaluate user-controlled content. The feature operates through two mechanisms:

1. Per-node scrubbing (_sanitizeElements, src/purify.ts:1403), scrubs individual text nodes during the main sanitization walk.
2. Final normalization pass (_scrubTemplateExpressions, src/purify.ts:1115), calls node.normalize() to merge adjacent text nodes, then walks the merged nodes and strips any expressions that only appeared after merging.

The Gap

_scrubTemplateExpressions uses a standard NodeIterator rooted at the output body:

// src/purify.ts:1117
const walker = createNodeIterator.call(
  node.ownerDocument || node,
  node,
  NodeFilter.SHOW_TEXT | NodeFilter.SHOW_COMMENT | ...,
  null
);

Per the DOM specification, a NodeIterator does not descend into <template>.content. The template element's content is a separate DocumentFragment that lives outside the normal child-node tree. For the same reason, node.normalize() (called on line 1116) also does not normalize text nodes inside <template>.content.

This means the final normalization and scrub pass, the only pass that catches expressions formed by merging split text nodes, never runs on <template> content.

How Split Text Nodes Are Created

When DOMPurify removes a disallowed element with KEEP_CONTENT: true (the default), it moves the element's text children into the parent node. This is the standard code path at src/purify.ts:1361–1373:

if (KEEP_CONTENT && !FORBID_CONTENTS[tagName]) {
  const parentNode = getParentNode(currentNode);
  const childNodes = getChildNodes(currentNode);
  if (childNodes && parentNode) {
    for (let i = childCount - 1; i >= 0; --i) {
      const childClone = cloneNode(childNodes[i], true);
      parentNode.insertBefore(childClone, getNextSibling(currentNode));
    }
  }
}

If the removed elements were adjacent siblings inside <template> content, their extracted text nodes end up as adjacent text nodes in the template content fragment. Each individual text node is scrubbed by _sanitizeElements, but since $ and {evil} do not match any expression regex on their own, neither is modified.

The code comment at src/purify.ts:1100 explicitly acknowledges the threat class:

"which only form after text-node normalization (e.g. fragments split across stripped elements) cannot survive into a template-evaluating framework."

The implementation guards against this on the main body, but the guard is not applied to <template> content.

Proof of Concept

Why the Split Works

The bypass relies on splitting ${...} across two adjacent custom elements so that neither fragment matches any DOMPurify regex on its own:

| Fragment | Against TMPLIT_EXPR /\${[\w\W]*/g | Against MUSTACHE_EXPR /{{[\w\W]*\|^[\w\W]*}}/g | Result | |---|---|---|---| | $ | Requires ${ - no { follows | No {{ or }} | Survives | | {alert(document.domain)} | Requires leading $ - absent | No {{, ends with single } not }} | Survives | | ${alert(document.domain)} | Full match - would be stripped | - | Stripped if seen whole |

DOMPurify only sees each fragment in isolation. It never merges them before…

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…

Impact

A DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied TRUSTED_TYPES_POLICY even after clearConfig() is called. A later caller that requests RETURN_TRUSTED_TYPE receives a TrustedHTML object created by the old policy, not by a clean default configuration.

If the old policy is unsafe or controlled by a less-trusted integration, this turns a later "default" sanitize call into script execution at a Trusted Types sink. TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy. dompurify-trusted-types-policy-survives-clearconfig-poc.js

Affected version

Tested against DOMPurify 3.4.8, repository commit 825e617753ac1169306a542d3174a77f717a0cf6.

Root cause

_parseConfig() overwrites trustedTypesPolicy when cfg.TRUSTED_TYPES_POLICY is truthy, but the default/null path only initializes the internal policy when trustedTypesPolicy === undefined. Once a custom policy has been set, later default config parsing leaves it in place.

Relevant code:

• src/purify.ts:786-812 accepts and stores cfg.TRUSTED_TYPES_POLICY.
• src/purify.ts:813-832 does not reset an existing policy when config has no policy or has TRUSTED_TYPES_POLICY: null.
• src/purify.ts:2123-2125 signs the final serialized HTML with the retained policy when RETURN_TRUSTED_TYPE is true.
• src/purify.ts:2133-2136 clearConfig() only clears CONFIG and SET_CONFIG; it does not reset trustedTypesPolicy or emptyHTML.

Local PoC

Run from the DOMPurify checkout, or set DOMPURIFY_REPO:

node /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js

Observed output:

{
  "result": {
    "baseline": "<b>baseline</b>",
    "duringPolicy": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterClearString": "<img src=\"x\">",
    "afterClearTrustedType": "[object TrustedHTML]",
    "afterClearTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterNullTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "mountedHTML": "<img src=\"x\" onerror=\"alert(&quot;TT_POLICY_SURVIVED_CLEARCONFIG&quot;)\">"
  },
  "dialogs": [
    "TT_POLICY_SURVIVED_CLEARCONFIG"
  ]
}

The important part is the split behavior after cleanup:

• purify.clearConfig(); purify.sanitize(...); returns a normal sanitized string (<img src="x">), because the later call is not asking for a Trusted Type.
• purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true }); still uses the old policy and returns attacker-controlled TrustedHTML.
• Passing { TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true } also still returns attacker-controlled TrustedHTML.

Preconditions

This is a shared-instance state contamination issue. It matters when one DOMPurify instance is reused by multiple integrations, plugins, request handlers, or components with different trust levels, and a cleanup step relies on clearConfig() to restore safe defaults.

This is not a default string-input bypass. An attacker must be able to influence a prior TRUSTED_TYPES_POLICY on the reused instance, or a less-trusted integration must have installed an unsafe policy.

Severity

impact is XSS at a Trusted Types sink in applications that reuse a DOMPurify instance across trust boundaries. Attack complexity is high because exploitation depends on prior policy injection or a less-trusted integration and a later RETURN_TRUSTED_TYPE sink.

Suggested fix

Make clearConfig() reset Trusted Types state as part of restoring defaults, or have _parseConfig() explicitly clear trustedTypesPolicy and emptyHTML when TRUSTED_TYPES_POLICY: null is supplied.

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 5 CVEs. Fixed in 2.5.8-tuxcare.4.

TuxCare rebuilt dompurify to address 7 CVEs. Fixed in 3.0.3-tuxcare.2.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.7-tuxcare.2.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.3-tuxcare.4.

TuxCare rebuilt dompurify to address 3 CVEs. Fixed in 2.5.9-tuxcare.4.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.0-tuxcare.2.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.5.8-tuxcare.5.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.3.0-tuxcare.3.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.7-tuxcare.3.

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

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.3-tuxcare.5.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.4.0-tuxcare.3.

TuxCare rebuilt dompurify to address 1 CVE. Fixed in 2.3.0-tuxcare.4.

TuxCare rebuilt dompurify to address 2 CVEs. Fixed in 2.4.7-tuxcare.4.

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.4.6-tuxcare.2.

TuxCare rebuilt dompurify to address 4 CVEs. Fixed in 3.4.7-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.

Summary

When DOMPurify.sanitize(root, { IN_PLACE: true }) is called on an attacker-supplied live DOM node, DOMPurify still trusts currentNode.nodeName for non-form nodes in the main _sanitizeElements pipeline. A real <script> child node whose observable nodeName is attacker-controlled can therefore be misclassified as an allowed element and retained. When the sanitized tree is inserted into a live document, the script executes.

This affects current 3.4.6. The recent IN_PLACE hardening work covers clobbered form handling and foreign-realm shadow/template traversal, but does not harden the main per-node element decision for hostile non-form live nodes.

Affected

• DOMPurify 3.4.6
• Any caller that does DOMPurify.sanitize(node, { IN_PLACE: true }) on attacker-supplied live DOM nodes
• Verified attacker-controlled node sources:
  • same-origin iframe → live node passed by reference
  • same-origin window.open() popup → live node passed by reference
  • same-origin foreign node adopted into the host document via document.adoptNode(node) and then sanitized in-place

Not affected:

• String-input DOMPurify.sanitize(dirtyString)

Vulnerability details

Code paths

[A] — _sanitizeElements uses the instance-visible nodeName for the allow/forbid decision:

const _sanitizeElements = function (currentNode: any): boolean {
  ...
  if (_isClobbered(currentNode)) {
    _forceRemove(currentNode);
    return true;
  }

  const tagName = transformCaseFunc(currentNode.nodeName);
  ...
  if (
    FORBID_TAGS[tagName] ||
    (!(...) && !ALLOWED_TAGS[tagName])
  ) {
    ...
    _forceRemove(currentNode);
    return true;
  }
  ...
};

For non-form nodes, _isClobbered(currentNode) returns false early. The subsequent element decision therefore trusts currentNode.nodeName directly.

[B] — _isClobbered is form-specific:

const _isClobbered = function (element: Element): boolean {
  const realTagName = getNodeName ? getNodeName(element) : null;
  if (typeof realTagName !== 'string') {
    return false;
  }

  if (transformCaseFunc(realTagName) !== 'form') {
    return false;
  }

  return (...);
};

The hardening is intentionally scoped to form. Non-form nodes are not checked for divergence between the instance-visible property view and the trusted prototype getter view.

Why the bypass works

The attack does not depend on string HTML parsing. It depends on a hostile live DOM object crossing a trust boundary into DOMPurify's IN_PLACE pipeline.

If the attacker controls a same-origin subcontext (iframe or popup), they can prepare a real DOM subtree there and then pass the live node object by reference to a host page that trusts DOMPurify.sanitize(node, { IN_PLACE: true }) as its final sanitization step.

For the verified primitive below:

• the real child node is <script>
• its script text is attacker-controlled
• the observable nodeName is attacker-controlled and made to appear as "DIV"
• _sanitizeElements therefore classifies the real <script> child as an allowed element
• the real <script> survives in the sanitized tree and executes on insertion

This primitive survives:

• direct reference passing
• document.adoptNode(node) followed by IN_PLACE

It does not survive:

• importNode
• cloneNode

because those paths materialize a fresh node and discard the hostile object semantics.

Proof of concept

(1) Minimal — runnable in a single browser context

<!doctype html>
<html><body>
<script src="dist/purify.js"></script>
<script>
  const foreign = window.open('about:blank', '_blank', 'noopener=no');

  const host = foreign.document.createElement('div');
  const script = foreign.document.createElement('script');
  script.textContent = 'window.__pwned = 1';
  Object.defineProperty(script, 'nodeName', {
    value: 'DIV',
    configurable: true,
  });
  host.appendChild(script);

  DOMPurify.sanitize(host, {…