DOMPurify EUVD-2026-97646

Exploitation requires the victim application to invoke DOMPurify.sanitize(node, { IN_PLACE: true }) AND to register an afterSanitizeElements or afterSanitizeAttributes hook that removes a non-root element; only then does the detached subtree escape neutralization and retain armed on* handlers on the live DOM. This is a non-default, application-specific configuration - IN_PLACE mode and node-removing afterSanitize hooks are not DOMPurify defaults - which sharply limits the affected population despite the library's broad deployment. Further limiting factors: the attacker only supplies markup (no authentication needed, PR:N) but active victim interaction is required to render the content (UI:A), and impact is confined to script execution in the victim origin (DOM XSS), not host compromise.

This is a genuine but conditional, moderate-risk DOM XSS (CVSS 4.0 base 5.1, Medium) rather than a widespread critical. The vector AV:N/AC:L/AT:N/PR:N/UI:A indicates network-reachable, unauthenticated triggering but requires active victim interaction (UI:A) and yields only low confidentiality/integrity impact on a subsequent system (VC:N/VI:N/VA:N, SC:L/SI:L), consistent with script execution in the victim origin rather than full system compromise. The signals do NOT suggest urgent mass-exploitation: there is no CISA KEV listing, no EPSS score was supplied in the input, and no public proof-of-concept is referenced - so exploitation status is 'no public exploit identified at time of analysis.' The real limiter is configuration dependency: the flaw only manifests when an application calls DOMPurify.sanitize with IN_PLACE:true AND registers a node-removing afterSanitizeElements/afterSanitizeAttributes hook, which the CVSS base vector does not capture (base AT:N arguably understates this prerequisite). Note a signal nuance to verify: the 4.0 vector marks AT:N (no special attack requirement) and AC:L, yet the advisory describes a fairly narrow non-default configuration, so defenders should treat real-world attack complexity as higher than the base vector implies. Priority is elevated chiefly because DOMPurify is a very widely embedded sanitization library, so even a narrow config pattern can appear across many downstream applications.

A victim web application sanitizes user-supplied HTML with DOMPurify in IN_PLACE mode and uses an afterSanitize hook that strips a wrapper element; an attacker submits markup placing on* handlers (e.g. an <img onerror=...>) inside that wrapper. When the hook removes the wrapper's root but the detached subtree is never neutralized, the queued event handler fires in the victim's origin after sanitize() returns, executing attacker script. No public exploit code is referenced, and the attack requires the victim app's specific IN_PLACE-plus-hook configuration plus user interaction (UI:A) to render the content.