DOMPurify CVE-2026-65911

Exploitation requires the target application to use DOMPurify in a specific multi-call pattern on a shared instance: (1) an initial sanitize() call must supply ADD_ATTR or ADD_TAGS as a JavaScript function predicate, establishing state in EXTRA_ELEMENT_HANDLING; (2) a subsequent sanitize() call on the same instance must supply ADD_ATTR or ADD_TAGS as an array rather than a function, failing to clear the previously registered handler. Single-call usage, per-call instantiation, or consistent use of only array-type options for ADD_ATTR and ADD_TAGS are all NOT vulnerable. Additionally, exploitation requires that a victim user interact with or render the unsanitized output in a browser context (UI:A per CVSS 4.0 vector). Deployments using DOMPurify without ADD_ATTR or ADD_TAGS options are not affected.

The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A/SC:L/SI:L) yields a score of 5.1 - moderate. The network attack vector and no-privileges-required metrics indicate that any network-reachable content submission path is potentially exploitable, but UI:A (active user interaction) and impact limited to the subsequent system (browser context) correctly constrain the score. The critical limiting factor is AC:L/AT:N in the official vector, which understates the practical deployment prerequisite: the target application must use the same DOMPurify instance across multiple sanitize() calls and must transition between function predicates and array values for ADD_ATTR or ADD_TAGS - a non-default and relatively uncommon usage pattern. EPSS data is not provided in the input; no KEV listing exists; no POC is confirmed. The vendor (Cure53) explicitly categorizes this as an edge case outside their threat model, suggesting real-world prevalence of the vulnerable call pattern is narrow. Despite DOMPurify's high deployment breadth, the specific two-call mixed-type pattern required to trigger state leakage significantly reduces the effective population of exploitable applications. This is best treated as a medium-priority upgrade rather than an emergency patch, unless an internal code audit confirms the vulnerable calling pattern is present.

An attacker submits HTML containing a malicious event-handler attribute (e.g., onerror or onmouseover) or a tag explicitly included in FORBID_TAGS to an application that sanitizes user content with DOMPurify. Because an earlier sanitize() call on the same instance used a permissive function predicate via ADD_ATTR, the handler remains active in EXTRA_ELEMENT_HANDLING; the later call's array-based config does not clear it, so the attacker's attribute passes through unsanitized and executes as JavaScript when a victim renders the output in a browser. No public exploit code is confirmed at time of analysis.