DOMPurify versions prior to 3.4.7 expose their internal DEFAULT_ALLOWED_TAGS and DEFAULT_ALLOWED_ATTR sets to the uponSanitizeElement and uponSanitizeAttribute hooks when no explicit configuration is supplied. A hook that mutates these fields permanently broadens the allowed lists, so subsequent sanitize calls inherit the widened defaults. This flaw is an input‑validation weakness identified as CWE‑501 and enables an attacker to inject a tag or attribute that survives sanitization and executes client‑side script. The impact is a cross‑site scripting vulnerability that can persist across multiple calls within the same runtime.

All applications that embed any DOMPurify <=3.4.5 library, especially those that rely on the default configuration, or that register custom hooks that may alter DEFAULT_ALLOWED_TAGS or DEFAULT_ALLOWED_ATTR. The issue does not affect versions 3.4.6 or later, which have been patched to prevent mutation of the default sets.

The likely attack vector is any client‑side context where an attacker‑controlled hook can be registered—such as a malicious plugin, a compromised script bundle, or a user‑supplied component that directly calls DOMPurify. Once the default lists are mutated, all future sanitizations, even with default settings, will accept the poisoned tags, leading to persistent cross‑site scripting. The CVSS score of 5.3 indicates moderate severity; the EPSS score of less than 1% suggests exploitation is currently unlikely, and the vulnerability is not listed in CISA KEV. However, any environment that allows hook registration presents a potential attack surface.