DOMPurify CVE-2026-65899

Exploitation requires all three of the following conditions to hold simultaneously: (1) A single DOMPurify instance (not separate instances) is reused across two or more distinct trust contexts within the same application - the classic pattern is a shared singleton in a frontend framework. (2) At least one earlier caller supplies a TRUSTED_TYPES_POLICY configuration option to that shared instance, and that policy is either permissive or attacker-influenced. (3) A later caller invokes clearConfig() (expecting state reset) followed by sanitize() with RETURN_TRUSTED_TYPE: true, requesting a TrustedHTML object for use at a Trusted Types sink. If RETURN_TRUSTED_TYPE is not used, the retained policy does not affect string output. If the application always creates a fresh DOMPurify instance per call context, this vulnerability is not reachable. Limiting factors: requires Trusted Types to be configured in the application, requires the RETURN_TRUSTED_TYPE API flag, and requires a shared-instance architecture - none of which are default for typical DOMPurify usage.

The CVSS 4.0 score of 5.1 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L reflects that impact is confined to the subsequent system (the browser application context) rather than the vulnerable library itself, and that active user interaction is required. The AC:L and AT:N assignments suggest the vendor views the base conditions as straightforward, though real-world exploitation is gated on a specific architecture: the application must share a DOMPurify instance across trust boundaries and use the RETURN_TRUSTED_TYPE API. This is a non-default usage pattern not found in every DOMPurify deployment, which functionally raises real-world attack complexity beyond what AC:L implies. No EPSS score is available in the provided data; given the conditional exploitation requirements and the absence of a KEV listing, mass exploitation appears unlikely. However, a public PoC is confirmed in the GHSA advisory, meaning an attacker with visibility into a vulnerable application's DOMPurify usage pattern can exploit this deterministically. The risk is highest in large frontend monorepos or micro-frontend architectures where multiple teams share a DOMPurify singleton and some teams may supply custom Trusted Types policies.

A micro-frontend application shares one DOMPurify instance; a less-trusted plugin integration sets a TRUSTED_TYPES_POLICY that permits arbitrary HTML (e.g., to render legacy rich-text content). The core application later calls clearConfig() and then sanitize(userInput, { RETURN_TRUSTED_TYPE: true }) expecting clean output for a Trusted Types-protected sink. Instead, the retained unsafe policy signs the output, and attacker-supplied markup such as <img src=x onerror=alert(1)> reaches the DOM and executes. A working PoC demonstrating this exact scenario is attached to GHSA-vxr8-fq34-vvx9 and confirmed to produce script execution alerts in the test environment.