EUVD-2026-48273Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AC:H reflects the cross-realm DOM architecture requirement; UI:R for victim page interaction; S:C and C:L/I:L capture limited XSS impact on the victim's browser session.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
DOMPurify's IN_PLACE sanitization mode silently bypasses XSS filtering when processing DOM elements sourced from a different JavaScript window context (e.g., an iframe's contentDocument), returning the unsanitized element - payloads intact - to the calling application. The private _isNode() function's instanceof check fails for foreign-realm nodes because prototype chains belong to distinct window objects, causing DOMPurify to misidentify the input, disable IN_PLACE mode silently, and pass through unfiltered content. The vendor has explicitly declined to issue a fix, categorizing this as outside DOMPurify's threat model, leaving all versions through 3.3.3 permanently exposed without a vendor-supplied remediation path.
Technical ContextAI
DOMPurify (CPE: cpe:2.3:a:cure53:dompurify:*:*:*:*:*:*:*:*) is a widely embedded JavaScript XSS sanitization library by Cure53, typically used to strip dangerous HTML and script content before rendering untrusted markup. Its IN_PLACE mode allows sanitization of live DOM nodes directly rather than processing HTML strings, which is more efficient but introduces realm-sensitivity. The root cause maps to CWE-754 (Improper Check for Unusual or Exceptional Conditions): the private _isNode() function performs a standard JavaScript instanceof check, which silently returns false when the node's prototype chain originates from a different realm (window/global object). This is a known JavaScript platform limitation - cross-realm type checking with instanceof is unreliable without explicit cross-realm guard logic. DOMPurify does not account for this case in its IN_PLACE code path, so rather than raising an error or refusing to process the node, it stringifies the element (producing '[object HTMLDivElement]'), silently resets the IN_PLACE flag to false, and returns the original DOM node unmodified. Any XSS payload embedded in that node survives the sanitization call entirely intact.
RemediationAI
No vendor-released patch exists and none is planned - the vendor considers this an edge case outside DOMPurify's defined threat model, confirmed by the advisory at https://github.com/cure53/DOMPurify/security/advisories/GHSA-4w3q-35jp-p934. The primary mitigation is to discontinue use of DOMPurify's IN_PLACE mode with DOM elements sourced from cross-realm contexts (iframes, popup windows, or any distinct browsing context). Applications should serialize foreign-realm content to an HTML string before passing it to DOMPurify (e.g., use element.outerHTML as input rather than the element itself); this trades a minor performance benefit for guaranteed sanitization. If IN_PLACE processing of cross-realm elements is architecturally unavoidable, implement a pre-check that validates instanceof against the element's own ownerDocument.defaultView before invoking DOMPurify, and reject or re-serialize elements that fail this check. Deploying a strict Content Security Policy (CSP) with script-src restrictions will not prevent the bypass but limits downstream XSS impact by constraining what injected scripts can do. Migrating cross-realm sanitization workflows to a Trusted Types policy or a DOMParser-based approach in the current window context are viable architectural alternatives for high-security deployments. No exact fix version can be cited because no patch is available.
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. Rated medium severity (CVSS 6
Cure53 DOMPurify before 2.0.17 allows mutation XSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exp
DOMPurify before 2.0.1 allows XSS because of innerHTML mutation XSS (mXSS) for an SVG element or a MATH element, as demo
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. Rated critical severity (CVSS
Mutation-XSS in DOMPurify before 3.3.2 enables JavaScript execution in victim browsers when sanitized output is re-inser
Hook mutation pollution in DOMPurify <= 3.4.5 allows persistent bypass of HTML sanitization defaults when application-in
Trusted Types policy state contamination in DOMPurify 3.0.0-3.4.8 allows a previously supplied TRUSTED_TYPES_POLICY to s
Prototype pollution in DOMPurify's USE_PROFILES mode enables DOM-based XSS by causing the sanitizer to accept event hand
URI validation bypass in DOMPurify 3.3.1 and earlier allows `javascript:` protocol payloads to survive HTML sanitization
SAFE_FOR_TEMPLATES bypass in DOMPurify 3.0.0-3.4.7 allows template expressions such as ${evil}, {{evil}}, and <%evil%> t
Cross-site scripting in DOMPurify 3.4.6 and earlier enables script execution when the library's IN_PLACE sanitization mo
Stored XSS is achievable in applications using DOMPurify's setConfig() API combined with an uponSanitizeAttribute hook t
Share
External POC / Exploit Code
Leaving vuln.today