DOMPurify CVE-2026-116804

Not a default-configuration flaw. ALL of the following must hold: (1) the application enables SAFE_FOR_TEMPLATES:true; (2) together with a DOM-returning mode - RETURN_DOM:true, RETURN_DOM_FRAGMENT:true, or IN_PLACE:true; (3) the sanitized input is a DOM node carrying an attached shadow root, created either programmatically via element.attachShadow or via declarative shadow DOM (attacker markup with <template shadowrootmode="open"> parsed through setHTMLUnsafe / Document.parseHTMLUnsafe); and (4) the application subsequently feeds the sanitized shadow root's textContent/innerHTML into a template evaluator that interprets {{...}}, ${...}, or <%...%>. Limiting factors: every one of these is non-default and application-specific; no impact occurs unless a downstream engine actually evaluates the expression; affected only in dompurify 3.4.4-3.4.16 (string sanitization without shadow roots, or non-DOM/non-template-safe modes, are not affected).

Signals converge on a genuine but conditional, mid-tier issue rather than an emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:A) scores 5.1 (medium) and models no impact to DOMPurify itself (VC/VI/VA:N) with low confidentiality/integrity impact to a subsequent system (SC:L/SI:L) - consistent with XSS landing in the downstream application rather than the library. EPSS is low (0.18%, 7th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_month' (not act_now/emergency). A complete, working proof-of-concept is published in the Cure53 GHSA advisory, so exploitability is demonstrated, but exploitation is gated by a chain of non-default preconditions (see exploitation_conditions), which is why real-world risk is materially lower than the CWE-79 class would suggest. Note a vector-vs-mechanism caveat: the official 4.0 vector uses AT:N, yet the advisory states exploitation 'requires non-default application configuration' - a specific environmental precondition that arguably warrants AT:P; the low EPSS despite a public PoC fits this precondition-heavy, non-commodity profile. Net: patch within normal cycles (vendor fix exists in 3.4.17); prioritize if your application actually enables SAFE_FOR_TEMPLATES with a DOM-returning mode and feeds sanitized output to a template engine.

A web application sanitizes attacker-influenced DOM (containing an attached shadow root) with DOMPurify configured as SAFE_FOR_TEMPLATES plus IN_PLACE/RETURN_DOM, then feeds the sanitized shadow root's textContent into a client- or server-side template engine. The attacker splits a template expression like ${alert(document.domain)} across text nodes separated by a disallowed element (e.g. <object>); after sanitization removes the separator the fragments merge into a complete expression that the template engine evaluates as script. The GHSA advisory includes a complete working PoC demonstrating injection of the attacker-chosen expression into post-sanitization shadow-root content.