GHSA-p98j-92pf-mc4p: XSS
Summary
In INPLACE mode DOMPurify sanitizes the caller's live DOM subtree directly. To close a known hazard (GHSA-55q2-fjhq-7xh7), the library neutralizes any node a hook detaches during sanitization by stripping its subtree's non-allow-listed attributes, but this neutralization is wired only into the beforeSanitizeElements and uponSanitizeElement hook sites. An afterSanitizeElements or afterSanitizeAttributes hook that removes a non-root element (a documented, supported pattern) detaches that element's subtree with no neutralization, so descendant on handlers remain armed on the caller's live tree after sanitize() returns, yielding DOM XSS. No special privilege is required beyond supplying markup to an application that uses INPLACE together with a node-removing afterSanitize hook.
Root Cause
INPLACE sanitization mutates the caller's live document, so any element a hook detaches from that tree must have its subtree neutralized before sanitize() returns; otherwise a queued resource-event handler (for example an <img onerror> that began loading when the caller built the tree) fires in page scope even though the handler never reached the sanitized output. The guard helper handleHookDetachedNode (which calls neutralizeSubtree in INPLACE) is invoked only after beforeSanitizeElements and after uponSanitizeElement. It is never invoked from the afterSanitize return paths, and sanitizeAttributes never calls it at all. The post-walk INPLACE neutralization pass iterates only DOMPurify.removed, and hook-detached nodes are intentionally not recorded there, so that pass cannot reach them either.
text src/purify.ts sanitizeElements: handleHookDetachedNode present at lines 2142 and 2175 (before/upon), absent after afterSanitizeElements at lines 2208 and 2249. sanitizeAttributes: afterSanitizeAttributes fires at line 2670 with no detach re-check; the function never calls handleHookDetachedNode. Post-walk INPLACE pass (lines 3081-3090) iterates DOMPurify.removed only, which by design (comment at lines 2096-2099) excludes hook-detached nodes.
Impact
An attacker who supplies markup processed by a victim application that runs DOMPurify.sanitize(node, { INPLACE: true }) and registers a node-removing afterSanitizeElements or afterSanitizeAttributes hook can retain arbitrary on event handlers on descendants of a removed non-root element. Because INPLACE operates on the caller's live document, a queued resource-event handler on such a descendant fires in the page origin after the synchronous sanitize() call returns, giving script execution in the victim's session (DOM XSS). This defeats DOMPurify's INPLACE contract to neutralize handlers on subtrees removed from the live tree. The capability is script execution in the victim origin; exact confidentiality and integrity effects depend on the hosting application's session.
Proof of Concept
text Dependencies: Node.js and jsdom. The harness builds a live tree, registers a removal hook, runs INPLACE sanitize(), then inspects whether the attacker onerror handler survives on the detached descendant. jsdom does not perform real image loads, so the retained handler (rather than an actual fired event) is the observed hazard; the retained on attribute on a live detached node after a synchronous sanitize() return is the neutralization failure.
Reproduction steps: 1. Build a live subtree #root > section#wrap > img[onerror] where #root is the walk root and section#wrap is a non-root wrapper. 2. Register an afterSanitizeElements (or afterSanitizeAttributes) hook that calls node.remove() on the wrapper. 3. Call DOMPurify.sanitize(root, { INPLACE: true }). 4. Observe that the descendant <img> retains its onerror handler, whereas the same removal performed in a beforeSanitizeElements/uponSanitizeElement hook strips it.
javascript const { JSDOM } = require('jsdom'); const createDOMPurify = require('dompurify'); const { window } = new JSDOM('<!DOCTYPE html><body></body>'); const DOMPurify = createDOMPurify(window);
const root = window.document.createElement('div'); root.id = 'root'; root.innerHTML = '<section id="wrap"><img src="x" onerror="ATTACKER()"></section>'; window.document.body.appendChild(root);
DOMPurify.addHook('afterSanitizeElements', (node) => { if (node.id === 'wrap') node.remove(); }); DOMPurify.sanitize(root, { INPLACE: true });
// The detached <img> still carries its onerror handler: console.log(root.querySelector('#wrap') === null, // true (removed from live tree) !!window.document.querySelector('img[onerror]') || // handler survives on the detached node root.innerHTML);
text PASS: beforeSanitizeElements detach neutralizes descendant onerror (control) PASS: uponSanitizeElement detach neutralizes descendant onerror (control) PASS: without a removal hook the descendant onerror is stripped normally PASS: afterSanitizeElements detach LEAVES descendant onerror armed (GAP) PASS: afterSanitizeAttributes detach LEAVES descendant onerror armed (GAP) PASS: kept custom element removed in afterSanitizeElements leaves descendant onerror armed (GAP)
Attack Chain
1. Exposure: The victim application calls DOMPurify.sanitize(liveNode, { INPLACE: true }) on attacker-influenced markup and has registered a node-removing afterSanitizeElements or afterSanitizeAttributes hook per an application policy (src/purify.ts:3026 walk, 2136 element pass, 2522 attribute pass). 2. Control: The attacker controls the markup, including a non-root wrapper element and, inside it, a descendant carrying an on resource-event handler such as <img src=x onerror=...>. 3. Path: The pre-order walk visits the wrapper before its descendants. During the wrapper's element or attribute pass the application hook detaches the wrapper from the live tree. 4. Guard: The detach-neutralization guard handleHookDetachedNode runs only after beforeSanitizeElements (2142) and uponSanitizeElement (2175); it is absent after afterSanitizeElements (2208, 2249) and is never called by sanitizeAttributes (afterSanitizeAttributes at 2670). The NodeIterator advances past the detached subtree, so the descendants are never revisited, and the post-walk pass iterates only DOMPurify.removed, which excludes hook-detached nodes. 5. Primitive: The descendant retains its on handler on the caller's live document after sanitize() returns. 6. Result: The queued resource event fires the attacker handler in the victim page origin, achieving DOM XSS despite INPLACE sanitization.
Bypass Evidence
The relevant prior fix is GHSA-55q2-fjhq-7xh7 ("INPLACE hook removal leaves a detached subtree executable, causing XSS"), whose change (#1557) added neutralizeSubtree at the beforeSanitizeElements and uponSanitizeElement detach sites. Inspection of that change shows it touches no afterSanitize site: the diff adds the neutralization only at the before/upon locations, later refactored into handleHookDetachedNode at src/purify.ts:2142 and 2175. A subsequent hardening change (#1616) added a rootWasRemoved throw and a neutralization sweep over DOMPurify.removed, but that sweep still iterates only DOMPurify.removed, which by design excludes hook-detached non-root nodes, so it does not close this gap. The afterSanitizeElements-on-kept-custom-element site at 2208 was itself introduced by the fix for GHSA-c2j3-45gr-mqc4 (#1527), adding another uncovered hook site.
Disproof attempts, all failed: (a) that a later release closed the afterSanitize gap, refuted by inspecting the published 3.4.13, 3.4.14, and 3.4.15 artifacts; (b) that detached descendants are revisited or re-sanitized, refuted at runtime (the onerror is retained only at the afterSanitize sites and stripped at the before/upon sites and with no removal hook); (c) that the post-walk pass catches hook-detached nodes, refuted by the design that excludes them from DOMPurify.removed; (d) that the precondition is contrived, refuted by parity with the accepted GHSA-55q2 threat model and the library's own supported pattern of removing a node inside afterSanitizeElements. The only edge not directly executed is the browser resource-event dispatch (jsdom performs no real image load); it is established by the proven retention of the live handler after a synchronous return, the library's own comments describing exactly this hazard, and parity with the accepted GHSA-55q2 mechanism.
Affected Versions
- Ecosystem: npm - Package: dompurify - Confirmed affected range: >= 3.4.13, <= 3.4.15 - Latest release checked: 3.4.15 (npm registry) - Fix status: fixed in 3.4.16
The before/upon detach neutralization introduced for GHSA-55q2-fjhq-7xh7 first shipped in 3.4.13; the residual afterSanitize gap was verified by reproducing it against the published npm artifacts for 3.4.13, 3.4.14, and 3.4.15. The 3.4.12 artifact predates that neutralization and behaves differently at the before/upon sites, so it is outside this specific incomplete-fix range. No release through 3.4.15 neutralizes detached subtrees at the afterSanitize sites, so no fixed version is established.
Suggested Fix
Enforce the same INPLACE detach-neutralization invariant at every hook site that can detach a node, not only the before/upon sites. Concretely, apply a handleHookDetachedNode(currentNode, root) re-check after afterSanitizeElements at both src/purify.ts:2208 and 2249 (returning as removed when the node was detached), and add an equivalent INPLACE detach check plus neutralizeSubtree after afterSanitizeAttributes at 2670. As an interim mitigation without a code change, applications using INPLACE can avoid removing nodes inside afterSanitizeElements/afterSanitizeAttributes hooks and instead perform such removals in beforeSanitizeElements/uponSanitizeElement, or avoid INPLACE for attacker-influenced content.
Reported by zx (GitHub: @manus-pi).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/dompurifyto a version that resolves this vulnerability.Fixed in 3.4.16 - Configuration
Avoid IN_PLACE sanitization for attacker-influenced content.
DOMPurify IN_PLACE = false - Configuration
Do not remove nodes inside afterSanitizeElements or afterSanitizeAttributes hooks; perform such removals in beforeSanitizeElements or uponSanitizeElement instead.
DOMPurify sanitization hooks node-removal hook timing = beforeSanitizeElements or uponSanitizeElement
Event History
Frequently Asked Questions
Which DOMPurify integrations are exposed to this issue?
Applications are exposed when they use DOMPurify in IN_PLACE mode and register an afterSanitizeElements or afterSanitizeAttributes hook that removes a non-root element. The issue concerns mutation of the caller's live DOM tree rather than sanitized output alone.
What does an attacker need to exploit this?
An attacker needs to supply markup to an application with the affected IN_PLACE configuration and a node-removing afterSanitize hook. No special privilege is required.
How can the issue lead to script execution if the removed node is not in the sanitized output?
A detached subtree can retain descendant event-handler attributes such as onerror on the caller's live tree. A queued resource event, such as an image load failure that began before sanitization, can then fire in page scope after sanitize() returns.