DOMPurify EUVD-2026-110511

Exploitation requires a specific, non-default application configuration: the app must call DOMPurify.sanitize() with IN_PLACE:true AND register a hook (any of beforeSanitizeElements, uponSanitizeElement, afterSanitizeElements, beforeSanitizeAttributes, or afterSanitizeAttributes) that removes a node other than the hook's own node - i.e. the current node's parent/ancestor or a not-yet-visited sibling (the 'drop the whole <figure> if its image is disallowed' pattern). The attacker-supplied markup must contain a deferred handler such as <img onerror> that is already loading so it fires after sanitize() returns. LIMITING FACTORS: default usage, non-IN_PLACE mode, and hooks that only remove their own node are NOT affected (the walker still strips those); impact is confined to the victim browser DOM (no server compromise); and the flaw depends on the application's own hook logic plus the resource load/error event firing, per the advisory's 'input plus an application choice' classification.

Signals point to a genuine but conditional, medium-severity issue rather than a widespread emergency. The vendor CVSS 4.0 score is 5.1 (medium) with AV:N/AC:L/PR:N but UI:A and only low subsequent-system confidentiality/integrity impact (SC:L/SI:L, VA/SA:N), consistent with DOM XSS that executes in the victim's browser without server-side compromise. EPSS is low at 0.16% (6th percentile) and the CVE is NOT in CISA KEV, so there is no indication of active or mass exploitation. A detailed, working proof-of-concept is published in the cure53 GHSA advisory (demonstrated under jsdom and in Chromium/Playwright), so exploit knowledge is fully public even though exploitation is not confirmed in the wild. The decisive risk limiter is the precondition: the flaw only triggers when an application uses IN_PLACE mode together with a hook that removes a node other than its own (a parent, ancestor, or not-yet-visited sibling); default DOMPurify usage is unaffected. Net: this is a real, patch-worthy flaw aligned with the vendor's 'this_month' priority (not act_now/emergency), elevated by DOMPurify's enormous deployment base but sharply narrowed by the non-default hook pattern required. SSVC-style technical impact is partial (browser-context script execution, not host takeover); automatability is effectively limited because it depends on a specific application coding choice, not a default code path.

An application sanitizes attacker-influenced HTML with DOMPurify.sanitize(content, {IN_PLACE: true}) and registers a hook (e.g. afterSanitizeAttributes) that drops a surrounding element - for example 'remove the whole <figure> if its image is disallowed.' The attacker submits markup such as <figure><img class=bad><img src=x onerror=alert(1)></figure>; when the hook removes the parent, the second image's onerror handler is never walked or neutralized and fires in the victim's browser after sanitize() returns, yielding DOM XSS. A full working PoC for this exact scenario is public in the GHSA advisory.