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

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
dompurify	3.4.0 → 3.4.12

---

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

v3.4.9: DOMPurify 3.4.9

Compare Source

• Further improved the handling of Trusted Types config options, thanks @​offset
• Further improved the handling of IN_PLACE sanitization, thanks @​mozfreddyb
• Added more test coverage for IN_PLACE and Trusted Types related usage
• Bumped several dependencies where possible
• Updated README and wiki with more accurate documentation & attack samples

v3.4.8: DOMPurify 3.4.8

Compare Source

• Cleaned up the repository root, renamed some and removed unneeded files
• Fixed an issue with handling of Trusted Types policies, thanks @​fulstadev
• Fixed the node iterator for better template scrubbing, thanks @​IamLeandrooooo
• Included formerly missing LICENSE-MPL in published npm package, thanks @​asamuzaK
• Bumped several dependencies where possible

v3.4.7: DOMPurify 3.4.7

Compare Source

• Hardened the handling of Shadow Roots when using IN_PLACE, thanks @​GameZoneHacker
• Removed a problem leading to permanent hook pollution, thanks @​offset
• Refactored the test suite and expanded test coverage significantly

v3.4.6: DOMPurify 3.4.6

Compare Source

• Fixed several issues with DOM Clobbering in IN_PLACE mode, thanks @​offset & @​Bankde
• Hardened the checks for cross-realm IN_PLACE and Shadow DOM sanitization, thanks @​offset & @​Bankde
• Added more test coverage for IN_PLACE and general DOM Clobbering attacks
• Bumped several dependencies where possible

v3.4.5: DOMPurify 3.4.5

Compare Source

• Fixed a bypass caused by the new HTML element selectedcontent added in 3.4.4, thanks @​KabirAcharya

Note that this is a security release for an issue introduced in 3.4.4 and should be upgraded to immediately.

v3.4.4: DOMPurify 3.4.4

Compare Source

• Added the selectedcontent element to default allow-list, thanks @​lukewarlow
• Added the command and commandfor attributes to default allowed-list, thanks @​lukewarlow
• Added better template scrubbing for IN_PLACE operations, thanks @​DEMON1A
• Added stronger checks for cross-realm windows, thanks @​DEMON1A & @​fg0x0
• Updated demo website and made sure it uses the latest from main
• Updated existing workflows, fuzzer, dependabot, etc., added more tests
• Bumped several dependencies where possible

🚨 This release had been flagged as deprecated, please use DOMPurify 3.4.5 instead 🚨

v3.4.3: DOMPurify 3.4.3

Compare Source

• Fixed an issue with handling of nested Shadow DOM trees, thanks @​fishjojo1
• Fixed the template regexes to be more robust against ReDoS attacks, thanks @​aleung27
• Updated the node iteration code to catch more Shadow DOM related issues
• Updated Playwright and added Node 26 to test matrix
• Updated existing workflows, fuzzer, release signing, etc., added more tests
• Bumped several dependencies where possible

v3.4.2: DOMPurify 3.4.2

Compare Source

• Fixed an issue with URI validation on attributes allowed via ADD_ATTR callback, thanks @​nelstrom
• Fixed an issue with source maps referring to non-existing files, thanks @​cmdcolin
• Updated existing workflows, fuzzer, release signing, etc., added more tests
• Bumped several dependencies where possible

v3.4.1: DOMPurify 3.4.1

Compare Source

• Fixed an issue with on-handler stripping for HTML-spec-reserved custom element names (font-face, color-profile, missing-glyph, font-face-src, font-face-uri, font-face-format, font-face-name) under permissive CUSTOM_ELEMENT_HANDLING
• Fixed a case-sensitivity gap in the annotation-xml check that allowed mixed-case variants to bypass the basic-custom-element exclusion in XHTML mode
• Fixed SANITIZE_NAMED_PROPS repeatedly prefixing already-prefixed id and name values on subsequent sanitization
• Fixed the IN_PLACE root-node check to explicitly guard against non-string nodeName (DOM-clobbering robustness)
• Removed a duplicate slot entry from the default HTML attribute allow-list
• Strengthened the fast-check fuzz harness with explicit XSS invariants, an expanded seed-payload corpus, an additional idempotence property for SANITIZE_NAMED_PROPS, and a negative-control assertion ensuring the invariants actually fire
• Added regression and pinning tests covering the above fixes and two accepted-behavior contracts (SAFE_FOR_TEMPLATES greedy scrub, hook-added attribute handling)
• Extended CodeQL analysis to run on 3.x and 2.x maintenance branches

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

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

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, 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.