DOMPurify CVE-2026-65914

Exploitation requires both conditions to be true simultaneously: (1) the application uses DOMPurify in a version prior to 3.3.2, AND (2) the application re-inserts DOMPurify-sanitized HTML into the DOM via innerHTML using one of the confirmed special wrapper elements - script, xmp, iframe, noembed, noframes, or noscript. This wrapper re-contextualization is an application-level pattern, not a default DOMPurify behavior; applications that set innerHTML directly without wrapping, or that use other insertion methods such as textContent, are not affected by this specific flaw. User interaction (CVSS UI:P) is required - a victim must load or interact with the page that performs the vulnerable reparse. No authentication or server-side privileges are required from the attacker (PR:N), as the payload is delivered through attacker-controlled input to the sanitization function. Exploitation is therefore scoped to web applications with this specific non-default rendering architecture.

The CVSS 4.0 score of 5.3 (SC:L/SI:L with VC:N/VI:N/VA:N) accurately reflects that impact is limited to the victim's browser session via subsequent-system JavaScript execution - not server-side or infrastructure compromise. UI:P (user interaction required) and the prerequisite of a specific application-level usage pattern (re-insertion into wrapper elements) are meaningful limiting factors. However, the existence of a working public PoC - confirmed in GHSA-h8r8-wccr-v5f2 - materially elevates exploitability above what the score alone suggests. DOMPurify's widespread adoption as a de facto standard sanitization library means the blast radius across the ecosystem is significant even if only a subset of deployments use the vulnerable wrapper reinsertion pattern. No CISA KEV listing exists, so confirmed mass exploitation is unverified. EPSS data was not provided in the input. Real-world priority is moderate-to-high for any application using DOMPurify for client-side sanitization and piping output through innerHTML with the listed wrapper elements - the PoC lowers the bar for opportunistic exploitation.

An attacker submits a crafted payload - such as <img src=x alt="</xmp><img src=x onerror=alert('xss')"> - to a web application that sanitizes user input with DOMPurify and then writes the sanitized string into a page via innerHTML wrapped in an xmp element. DOMPurify passes the payload through unchanged, as the </xmp> sequence inside the alt attribute is not flagged in the initial parse context. When the application's innerHTML assignment triggers a second browser parse under the xmp wrapper context, the </xmp> closes the wrapper early and the injected <img onerror=...> is instantiated as a live DOM node, executing arbitrary JavaScript in the victim's browser. A complete working demonstration application is included in the GHSA advisory.