CVE-2026-65904 in DOMPurify
Summary
by MITRE • 07/23/2026
DOMPurify through 3.3.3 fails to sanitize DOM elements passed via IN_PLACE mode when the element originates from a different window/realm (e.g., an iframe's contentDocument). A cross-realm instanceof check in the private _isNode() function returns false for foreign-realm nodes, causing DOMPurify to stringify the element (yielding '[object HTMLDivElement]'), silently reset IN_PLACE to false, and return the unsanitized element unchanged with any XSS payloads intact. The vendor considers this an edge case outside DOMPurify's threat model and, at time of publication, no fix was planned.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/23/2026
DOMPurify vulnerability in versions up to 3.3.3 represents a critical security flaw that undermines the library's core sanitization capabilities when processing DOM elements from different execution contexts. This issue specifically affects the IN_PLACE mode functionality where the library attempts to sanitize elements directly within their existing document context rather than creating new sanitized copies. The vulnerability stems from a fundamental mismatch in how JavaScript's instanceof operator behaves across different window realms, particularly when elements originate from iframes or other cross-realm contexts.
The technical root cause lies within DOMPurify's private _isNode() function which performs cross-realm instanceof checks to determine if an element is a legitimate DOM node. When elements come from different windows or execution contexts such as iframe contentDocument objects, these instanceof checks fail because the constructor references don't match across realms despite the objects being functionally identical DOM elements. This failure causes the sanitization process to incorrectly identify foreign-realm nodes as non-entities, triggering an automatic fallback mechanism that converts the element to a string representation like '[object HTMLDivElement]' before returning it unmodified.
This behavior creates a dangerous security scenario where XSS payloads embedded within DOM elements originating from different realms remain completely intact and unsanitized. The vulnerability operates silently without any error messages or warnings, making it particularly insidious as it can bypass all security checks that would normally be applied to prevent cross-site scripting attacks. The flaw essentially allows attackers to inject malicious content through iframe-based vectors or other cross-realm DOM manipulations where the element's original context has been altered but DOMPurify fails to recognize and sanitize these elements properly.
The operational impact of this vulnerability extends beyond simple XSS prevention, as it fundamentally breaks the security assumptions that developers rely upon when using DOMPurify for content sanitization. Security teams and application developers who implement DOMPurify in applications that handle user-generated content from iframes or other cross-realm sources may unknowingly leave their applications vulnerable to persistent XSS attacks. This issue particularly affects web applications that dynamically load content through iframes, embed external resources, or utilize complex DOM manipulation patterns where elements might originate from different execution contexts.
From a threat modeling perspective, this vulnerability aligns with ATT&CK technique T1203 (Exploitation for Client Execution) and CWE-79 (Cross-site Scripting) while demonstrating weaknesses in input validation and object type checking. The vendor's decision not to address this issue as an edge case outside their threat model creates a significant gap in security coverage, particularly for applications that legitimately need to process cross-realm DOM elements. Organizations using DOMPurify must consider implementing additional defensive measures such as explicit realm checking, element context validation, or alternative sanitization approaches when dealing with iframe content and cross-document DOM manipulations.
Recommended mitigations include avoiding IN_PLACE mode when processing foreign-realm elements, implementing custom validation layers that explicitly check element origins before sanitization, or upgrading to versions where this issue has been addressed. Security teams should also consider monitoring for potential exploitation attempts through iframes or cross-domain content loading patterns and implement comprehensive testing procedures that specifically validate DOMPurify's behavior with cross-realm elements. The vulnerability underscores the importance of thorough testing across all execution contexts when implementing security libraries, particularly those dealing with DOM manipulation and sanitization where context awareness is critical for maintaining security boundaries.