DOMPurify CVE-2026-65904

Exploitation requires two simultaneous application-level conditions to be met: first, the application must explicitly invoke DOMPurify with the IN_PLACE mode option enabled - this is not the default behavior and must be deliberately configured by the developer; second, the DOM element passed to DOMPurify must originate from a different JavaScript realm, specifically from a cross-realm document such as an iframe's contentDocument, a popup window opened via window.open(), or any other browsing context with a distinct window/global object. Standard DOMPurify usage - passing HTML strings, or passing same-realm DOM nodes - is entirely unaffected by this vulnerability. Exploitation is further constrained by the attacker's need to control or inject content into the cross-realm document (requiring either a same-origin relationship with the iframe source or another injection vector), and by the requirement for user interaction (UI:P) to load and trigger the affected page. The vendor's explicit scoping of this as outside the threat model confirms these conditions are edge-case rather than mainstream usage patterns.

The CVSS 4.0 score of 2.3 is intentionally low and accurately reflects genuine exploitation constraints: AC:H captures the prerequisite that the calling application must be architected to retrieve DOM elements from a cross-realm context, AT:P encodes the specific attack condition (IN_PLACE mode explicitly enabled plus cross-realm element source), and UI:P requires victim interaction with the vulnerable page. The score's subsequent-system impact (SC:L/SI:L) reflects that successful exploitation results in limited XSS in the victim's browser session rather than server-side compromise. No EPSS data was provided; given AC:H and AT:P, real-world exploitation probability is assessed as low, as it depends on a narrow application architecture pattern. No KEV listing has been confirmed, and no public POC exploit has been identified at time of analysis. The material risk amplifier is the vendor's explicit refusal to patch - all DOMPurify deployments through 3.3.3 remain permanently exposed to this specific bypass without an upstream fix, which shifts remediation burden entirely to application developers. Security teams should prioritize this issue proportionally: low immediate exploitation risk, but architecturally significant for applications that explicitly use IN_PLACE mode with cross-frame content.

An attacker who can influence content within a same-origin iframe targeted by a web application retrieves a malicious DOM element from that iframe's contentDocument and ensures the application passes it to DOMPurify with IN_PLACE mode enabled. Because DOMPurify's instanceof check fails across realm boundaries, the XSS payload embedded in the element survives sanitization and is inserted into the parent document, executing arbitrary script in the victim's browser session. No public POC has been identified at time of analysis, but the bypass mechanism is described with sufficient technical specificity in the vendor advisory to be independently reproducible.