CVE-2026-65899

What it actually does

DOMPurify versions 3.0.0 through before 3.4.9 can retain a previously configured Trusted Types policy after clearConfig() is called. If the same DOMPurify instance is reused across different trust boundaries, a later sanitization call requesting RETURN_TRUSTED_TYPE may receive a TrustedHTML object produced by the earlier retained policy rather than a clean/default policy. If that retained policy is overly permissive or attacker-influenced, sanitized output can be accepted by browser Trusted Types enforcement and assigned to a Trusted Types sink, enabling cross-site scripting in affected application code paths. Passing TRUSTED_TYPES_POLICY: null does not reliably clear the retained policy in vulnerable versions.

Why it matters to the business

Applications that rely on DOMPurify and browser Trusted Types as an XSS control may have a bypass in specific reuse patterns, potentially allowing attackers to run JavaScript in a user's browser. Successful exploitation can lead to session theft, account actions performed as the victim, data exposure in the browser, fraudulent transactions, or compromise of administrative workflows. The issue has moderate severity, low EPSS, is not currently listed in CISA KEV, and has no known exploit maturity in the provided data, but DOMPurify is commonly embedded in web applications and downstream packages, so exposure may be indirect through bundled frontend dependencies.

How an attack unfolds

An attacker first needs a vulnerable application path where DOMPurify 3.0.0 to before 3.4.9 is used in a long-lived or shared instance across trust boundaries, and where one caller configures a custom TRUSTED_TYPES_POLICY. The attacker then causes or waits for that instance to be reused after clearConfig() is called. Because the vulnerable implementation does not reset the retained Trusted Types policy, the next caller can request RETURN_TRUSTED_TYPE and receive TrustedHTML generated under the old policy. If attacker-controlled markup reaches that path and the retained policy fails to sanitize or validate as strictly as expected, the application may place the resulting TrustedHTML into a Trusted Types-protected DOM sink. The browser treats the value as trusted, allowing script-capable content to execute in the victim's session. User interaction is likely required because the payload generally executes when a victim views or interacts with malicious or attacker-influenced content in the affected web application.

How to fix it

Upgrade DOMPurify to version 3.4.9 or later wherever it is directly or transitively used. If DOMPurify is bundled into an application, rebuild and redeploy frontend assets after upgrading the dependency; do not rely only on package-lock changes without verifying the shipped bundle. As a mitigation until upgrade, avoid reusing DOMPurify instances across trust boundaries, avoid mutable global/shared DOMPurify configuration for untrusted contexts, do not rely on clearConfig() or TRUSTED_TYPES_POLICY: null to clear a policy in affected versions, and instantiate isolated sanitizers for contexts with different trust assumptions. Review custom Trusted Types policies and ensure they do not return unsafe HTML or bypass sanitization. Maintain Content Security Policy and Trusted Types enforcement, but treat them as defense-in-depth rather than a complete mitigation for this specific retained-policy bug.

How to confirm the fix worked

Confirm all resolved DOMPurify versions are 3.4.9 or later in package manifests, lockfiles, software composition analysis results, and production bundles. For npm-based projects, check package-lock.json, yarn.lock, pnpm-lock.yaml, node_modules/dompurify/package.json, and generated JavaScript bundles for embedded DOMPurify versions. Add or run regression tests that configure a custom TRUSTED_TYPES_POLICY, call clearConfig(), then request RETURN_TRUSTED_TYPE and verify that the old policy is not reused. Review source code for shared DOMPurify instances used across components or trust boundaries, especially call sequences involving setConfig(), clearConfig(), TRUSTED_TYPES_POLICY, RETURN_TRUSTED_TYPE, and assignments to innerHTML or other Trusted Types sinks. In browsers with Trusted Types enabled, validate that sanitized output is produced by the expected policy after configuration reset.

Typical attack path

1. Identify a web application or bundled frontend package using DOMPurify versions 3.0.0 through before 3.4.9.
2. Find an application flow where a DOMPurify instance is reused across components, tenants, plugins, frames, or other trust boundaries.
3. Identify a prior flow that configures a custom TRUSTED_TYPES_POLICY and later calls clearConfig().
4. Supply or influence HTML content that will be sanitized by the reused instance after the configuration reset is expected.
5. Trigger a later sanitization call that requests RETURN_TRUSTED_TYPE, causing output to be created with the retained old policy.
6. Have the victim load the affected page or UI state so the TrustedHTML value is assigned to a Trusted Types sink.
7. Execute JavaScript in the victim's browser context if the retained policy permits unsafe content.

How to detect it

Detecting prior exploitation is difficult because successful exploitation occurs in the browser and may not leave a distinctive server-side signature. Start with exposure identification: search source repositories and built assets for DOMPurify versions before 3.4.9 and for code paths using TRUSTED_TYPES_POLICY, RETURN_TRUSTED_TYPE, clearConfig(), and shared DOMPurify instances. Review web access logs for requests that submit, store, preview, or render user-controlled HTML shortly before suspicious user activity. Examine CSP and Trusted Types violation reports, browser telemetry, RUM logs, and frontend error logs for unexpected script execution, blocked inline scripts, unusual DOM sink usage, or policy-name anomalies. Investigate application audit logs for account changes, privilege changes, token/API-key creation, unauthorized transactions, or administrative actions occurring after users viewed attacker-controlled content. If available, correlate suspect content submissions with victim page views and subsequent actions from the victim's session, IP address, or user agent. There are no universal network or file-system IOCs for this vulnerability; useful detections are primarily behavioral and application-specific.

What your security team should do

• Inventory applications and frontend packages that include DOMPurify, including transitive and bundled copies.
• Prioritize upgrades to DOMPurify 3.4.9 or later for internet-facing applications, administrative interfaces, applications handling user-generated HTML, and systems with privileged browser workflows.
• Search code for shared DOMPurify instances and the use of TRUSTED_TYPES_POLICY, RETURN_TRUSTED_TYPE, and clearConfig(); escalate findings for secure code review.
• Review custom Trusted Types policies for unsafe createHTML behavior or policies that simply return input.
• Rebuild and redeploy production frontend bundles after dependency updates, then verify the deployed artifact contains the fixed version.
• Add regression tests for Trusted Types policy reset behavior to prevent reintroduction during refactoring.
• Monitor for suspicious client-side script execution reports, CSP violation reports, and anomalous user actions consistent with XSS-driven account misuse.
• Because EPSS is currently low and the issue is not KEV-listed, treat this as a targeted remediation item rather than an emergency internet-wide incident unless affected applications process untrusted HTML or expose privileged workflows.