DOMPurify CVE-2026-65901

Exploitation requires three simultaneous conditions: (1) the vulnerable application must call DOMPurify.sanitize() with the IN_PLACE: true option - the default string-based sanitization path is entirely unaffected; (2) the node supplied to sanitize() must be a live DOM object under attacker influence, specifically delivered via a same-origin iframe (node passed by reference), a same-origin window.open() popup (node passed by reference), or a node adopted into the host document via document.adoptNode() before sanitization; and (3) a same-origin relationship must exist between the attacker's context and the target, which typically requires the attacker to control a resource on the same origin as the application (e.g., via a stored XSS vector, an open redirect to a same-origin page, or postMessage abuse). The attack does not apply to string HTML inputs, cross-origin iframes (blocked by same-origin policy), or any code path that does not use IN_PLACE mode. Limits on real-world exploitation: the same-origin requirement is a meaningful prerequisite, and most typical DOMPurify integrations sanitize HTML strings rather than live DOM nodes in IN_PLACE mode.

The CVSS 4.0 score of 5.1 (AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N) reflects a medium-severity finding with the scope of impact limited to the subsequent system (victim browser), not the vulnerable system itself. The UI:A (active user interaction) metric and the constrained attack surface - exploitation is gated on the application calling sanitize() in IN_PLACE mode AND accepting attacker-controlled live DOM nodes - significantly reduce real-world risk compared to a generic XSS in a web application. DOMPurify is a security control, so bypass of its sanitization is categorically more serious than an equivalent flaw in business logic: developers place explicit trust in it. No KEV listing exists, and no standalone POC code has been published; however, the GHSA advisory discloses code-level detail (exact function names, guard conditions, and three concrete exploit vectors) that materially lowers the barrier to exploitation. EPSS data was not supplied. The absence of a fix version (fixed in: None) elevates urgency for any caller using IN_PLACE mode. The assigned CVSS 4.0 AC:L is arguably generous given the required same-origin relationship and specific API usage; real-world complexity is higher than AC:L implies.

An attacker hosts a malicious page that opens a same-origin popup or embeds a same-origin iframe, constructs a live DOM node with a real script child whose nodeName property is clobbered to reflect an allowed tag name, and passes that node by reference to a vulnerable application calling DOMPurify.sanitize(node, { IN_PLACE: true }). DOMPurify's _sanitizeElements pipeline trusts the clobbered nodeName, retains the script element, and when the sanitized tree is inserted into the host document the script executes in the victim's browser context. No standalone POC has been published, but the GHSA advisory provides sufficient code-level detail to reconstruct the exploit.