CVE-2026-65901

What it actually does

DOMPurify through version 3.4.6 can fail to remove executable content when used in IN_PLACE mode on attacker-controlled live DOM nodes. The flaw stems from trusting an observable, attacker-clobbered nodeName value on live non-form nodes; a hostile DOM object can appear to be an allowed element while still containing real script-bearing children. When the sanitized tree is later inserted into an active document, attacker-controlled JavaScript can execute in the victim’s browser context. This is a client-side cross-site scripting issue requiring user interaction, such as a victim viewing or interacting with content that the application sanitizes and renders.

Why it matters to the business

Applications that rely on affected DOMPurify versions for browser-side HTML sanitization may expose users to script execution in trusted application pages. Successful exploitation can lead to session theft where cookies or tokens are accessible to JavaScript, account actions performed as the victim, malicious redirects, phishing overlays, data exposure from the page, or abuse of trusted application workflows. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, but DOMPurify is widely used across modern web applications, so affected code paths can be difficult to inventory and should be remediated promptly.

How an attack unfolds

An attacker first identifies a feature that accepts, transforms, previews, imports, or renders user-influenced HTML or DOM content using DOMPurify in IN_PLACE mode. The attacker then crafts a live DOM structure where the observable nodeName is clobbered to resemble an allowed element while the underlying structure contains executable script children or script-triggering content. The application invokes DOMPurify on that live node and, because of the flawed trust boundary, the sanitizer treats the hostile node as safe. When the application inserts the supposedly sanitized tree into the live document, the embedded script executes in the victim’s browser under the application origin. From there, the attacker can perform same-origin actions available to the victim, read page-accessible sensitive data, manipulate the UI, or pivot to credential/session theft depending on browser protections and application design.

How to fix it

Upgrade DOMPurify to a version newer than 3.4.6 that the DOMPurify maintainers designate as fixed. If exact fixed versions are not yet tracked internally, monitor the upstream DOMPurify release notes and package advisories, then pin and deploy the patched version across npm, bundled frontend assets, vendored JavaScript, CDN references, and transitive package copies. As an interim mitigation, avoid using IN_PLACE mode on attacker-controlled or user-influenced live DOM nodes; sanitize inert markup instead, such as strings or detached/inert documents, and only insert sanitized output after validation. Enforce a restrictive Content Security Policy that avoids unsafe-inline, uses nonces or hashes, and reports violations, but do not treat CSP as a substitute for upgrading. Review rich-text editors, markdown/HTML renderers, previews, importers, comments, messaging features, profile fields, admin consoles, and any component that sanitizes client-side DOM content.

How to confirm the fix worked

Confirm that no deployed application bundle, lockfile, CDN reference, vendored script, or transitive dependency uses DOMPurify version 3.4.6 or earlier. Search source and built artifacts for DOMPurify usage with IN_PLACE enabled, including minified bundles where practical. Validate package-manager output using commands such as npm ls dompurify, yarn why dompurify, pnpm why dompurify, software composition analysis, and SBOM comparison. After upgrading, rebuild and redeploy frontend assets, clear CDN/browser caches where relevant, and verify the browser actually loads the patched DOMPurify code. Regression-test affected rendering paths with benign and malicious HTML/DOM test cases to ensure script elements, event handlers, javascript: URLs, SVG/MathML script paths, and clobbered DOM constructs are removed or neutralized before insertion. Confirm CSP reports and browser developer tools show no unexpected script execution from sanitized user content.

Typical attack path

1. Find a web application path that uses DOMPurify through 3.4.6 with IN_PLACE mode enabled.
2. Identify a user-controlled input, plugin, import, editor, preview, or client-side rendering flow that can produce or influence live DOM nodes.
3. Craft a malicious live DOM object whose observable nodeName appears allowed while it retains executable script children or script-triggering content.
4. Deliver the malicious content to a victim through stored content, shared links, comments, messages, uploads, or another application workflow.
5. Wait for the victim to open or interact with the affected page so the application sanitizes the attacker-controlled live node.
6. Cause the application to insert the sanitized tree into a live document.
7. Execute JavaScript in the victim’s browser context and abuse the user’s application privileges or accessible data.

How to detect it

There are no universal network or host indicators for this client-side XSS because payloads depend heavily on the application feature and may execute only in the victim’s browser. To investigate possible exploitation, focus on features that render user-controlled HTML or DOM content through DOMPurify IN_PLACE mode. Review web access logs, WAF logs, application audit logs, content creation/update histories, rich-text editor submissions, uploaded/imported HTML, message/comment/profile fields, and API requests that store or render markup. Look for unusual markup patterns, attempts to create clobbered DOM structures, script-bearing children hidden inside apparently allowed elements, encoded script tags, event-handler attributes, javascript: URLs, SVG/MathML abuse, iframes, data URLs, and payloads followed by victim page views. Collect browser-side telemetry where available, including CSP violation reports, frontend error logs, real-user monitoring, session replay security events, and reports of unexpected redirects or UI overlays. Investigate anomalous same-origin actions occurring immediately after a user viewed attacker-controlled content, such as account setting changes, token use from new locations, unexpected administrative actions, or suspicious API calls made with legitimate user sessions. Because this issue is not in KEV and no exploit maturity is reported in the provided data, absence of known campaign indicators should not be treated as proof of non-exploitation.

What your security team should do

• Inventory DOMPurify usage across repositories, package lockfiles, built frontend bundles, CDN includes, and vendored third-party assets.
• Prioritize applications that render user-generated HTML, rich text, messages, comments, uploaded content, profile data, previews, or administrative content using browser-side sanitization.
• Upgrade all DOMPurify instances through 3.4.6 to a maintainer-confirmed fixed release and pin the patched version in dependency manifests and lockfiles.
• Temporarily disable or refactor IN_PLACE sanitization for attacker-controlled live DOM nodes until patched code is deployed.
• Add automated SCA and CI checks that fail builds on DOMPurify versions at or below 3.4.6.
• Deploy or tighten CSP with nonce- or hash-based script execution and CSP reporting to reduce exploit impact and improve detection.
• Review recent changes and telemetry for affected rendering features, especially stored content created since publication on 2026-07-23.
• Create regression tests for sanitizer bypass payloads and ensure future frontend changes do not reintroduce IN_PLACE use on untrusted DOM nodes.