Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability, identified as GHSA-p98j-92pf-mc4p, exists in DOMPurify's IN_PLACE sanitization mode. The root cause is the failure to neutralize event handlers on DOM subtrees that are detached by afterSanitizeElements or afterSanitizeAttributes hooks. The library's neutralization logic, encapsulated in the _handleHookDetachedNode function, was correctly applied for beforeSanitize* hooks but was missing for afterSanitize* hooks.
The analysis of the fixing commit b9b9d80f7e401771c2ccaef5f45def7eec8f27d7 confirms this. The patch modifies src/purify.ts to add calls to _handleHookDetachedNode at the points where afterSanitizeElements and afterSanitizeAttributes hooks are executed.
Specifically:
_sanitizeElements function, a check is added immediately after the afterSanitizeElements hook is called. This function is responsible for iterating through and sanitizing DOM elements._sanitizeAttributes function, a similar check is added after the afterSanitizeAttributes hook is invoked. This function handles the sanitization of attributes on a given element.During exploitation, an attacker would provide malicious HTML that, when processed by an application using a vulnerable DOMPurify version with IN_PLACE mode and a node-removing afterSanitize* hook, would trigger these functions. A runtime profile would show DOMPurify.sanitize calling the internal functions _sanitizeElements and _sanitizeAttributes, which contained the flawed logic. Therefore, these two functions are identified as the vulnerable functions.
_sanitizeElementssrc/purify.ts
_sanitizeAttributessrc/purify.ts
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| dompurify | npm | >= 3.4.13, <= 3.4.15 | 3.4.16 |
An attacker who supplies markup processed by a victim application that runs DOMPurify.sanitize(node, { IN_PLACE: 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 IN_PLACE 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 IN_PLACE 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.
Dependencies: Node.js and jsdom. The harness builds a live tree, registers a
removal hook, runs IN_PLACE 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:
#root > section#wrap > img[onerror] where #root is the walk root and section#wrap is a non-root wrapper.afterSanitizeElements (or afterSanitizeAttributes) hook that calls node.remove() on the wrapper.DOMPurify.sanitize(root, { IN_PLACE: true }).<img> retains its onerror handler, whereas the same removal performed in a beforeSanitizeElements/uponSanitizeElement hook strips it.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, { IN_PLACE: 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);
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)
DOMPurify.sanitize(liveNode, { IN_PLACE: 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).on* resource-event handler such as <img src=x onerror=...>._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.on* handler on the caller's live document after sanitize() returns.IN_PLACE sanitization.The relevant prior fix is GHSA-55q2-fjhq-7xh7 ("IN_PLACE 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.
Ecosystem: npmPackage: dompurifyConfirmed affected range: >= 3.4.13, <= 3.4.15Latest release checked: 3.4.15 (npm registry)Fix status: fixed in 3.4.16The 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.
Enforce the same IN_PLACE 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 IN_PLACE detach check plus _neutralizeSubtree after afterSanitizeAttributes at 2670. As an interim mitigation without a code change, applications using IN_PLACE can avoid removing nodes inside afterSanitizeElements/afterSanitizeAttributes hooks and instead perform such removals in beforeSanitizeElements/uponSanitizeElement, or avoid IN_PLACE for attacker-influenced content.
Reported by zx (GitHub: @manus-pi).
JavaScriptJavaScript