DOMPurify EUVD-2026-48271

Exploitation requires two simultaneous conditions in the target application: (1) a uponSanitizeElement or uponSanitizeAttribute hook must be installed that writes to data.allowedTags[tagName] = true or data.allowedAttributes[attrName] = true - this is described in the advisory as a natural-looking pattern for 'allow X for this iteration' and is not unusual in applications that conditionally permit additional elements; and (2) the application must subsequently call sanitize() on attacker-influenced input using the default configuration, meaning without explicit cfg.ALLOWED_TAGS or cfg.ALLOWED_ATTR arrays overriding the defaults. Applications that never install hooks of this type are not exploitable. Applications that always pass explicit allow-lists to every sanitize() call are not exploitable even if they install mutating hooks. The CVSS 4.0 UI:P metric reflects that the hook mutation (the poisoning event) must occur before the attacker's payload is processed, introducing a timing dependency. The scope of the impact is bounded to the same DOMPurify instance; separate instances or fresh constructions are unaffected.

The CVSS 4.0 base score of 5.3 (Medium, vector AV:N/AC:L/AT:N/PR:N/UI:P) characterizes this as network-accessible with low attack complexity and no privilege requirements, but dependent on user interaction. The VC:L/VI:L/SC:L/SI:L impact metrics reflect limited but real confidentiality and integrity bypass on both the vulnerable and subsequent-system surfaces, consistent with XSS enablement rather than full remote code execution. No EPSS score was provided in the source data; exploitation probability cannot be independently quantified. The vulnerability is not in CISA KEV, and no confirmed POC exists at time of analysis. Real-world risk is substantially mediated by the attack precondition: the target application must have an installed hook that writes to data.allowedTags or data.allowedAttributes, a pattern that, while natural-looking, is not universal across all DOMPurify deployments. However, the insidious nature of the state corruption - which cannot be cleared by removeAllHooks(), clearConfig(), or passing a fresh cfg, and requires constructing an entirely new DOMPurify instance - means applications unaware of the issue cannot self-recover through conventional remediation patterns. Given DOMPurify's broad deployment in content-rendering pipelines, any application with the requisite hook pattern is silently at persistent XSS risk.

An attacker targets a web application using DOMPurify with a uponSanitizeElement hook that writes data.allowedTags['script'] = true during a legitimate conditional rendering flow (e.g., to allow a custom element for a specific trusted content type). Once that hook executes once - triggered by any sanitize() call processing content that includes the relevant element - the global DEFAULT_ALLOWED_TAGS set is permanently widened to include 'script'. From that point forward, all subsequent sanitize() calls on the same DOMPurify instance, including those processing user-submitted comment or profile content, will pass through <script> tags, enabling stored XSS that executes in every visiting user's browser. No public exploit code has been identified at time of analysis.