DOMPurify from 3.4.4 before 3.4.17 SAFE_FOR_TEMPLATES Bypass via Shadow Root Content
DOMPurify from 3.4.4 before 3.4.17 contains a SAFE_FOR_TEMPLATES bypass that lets attackers preserve template expressions in attached shadow roots when using RETURN_DOM, RETURN_DOM_FRAGMENT, or IN_PLACE modes. Attackers can split expressions across text nodes separated by disallowed elements, which merge after removal and are evaluated by downstream template engines for cross-site scripting.
DOMPurify before 3.4.17 DOM XSS via IN_PLACE Hook-Detached Subtrees
DOMPurify before 3.4.17 contains a cross-site scripting vulnerability that allows attackers to keep event handlers armed when an IN_PLACE hook removes a parent or sibling node. Attacker markup in detached subtrees is never walked or neutralized, so handlers like img onerror fire after sanitize() returns, causing DOM XSS.
DOMPurify before 3.4.17 XSS via SMIL attributeName Guard Bypass in XHTML Mode
DOMPurify before 3.4.17 contains a cross-site scripting vulnerability that allows attackers to bypass the SMIL attributeName=href guard when PARSER_MEDIA_TYPE is application/xhtml+xml, because transformCaseFunc does not lowercase attribute names. Attackers can submit SVG with an animate or set element using attributeName="href" and a javascript: entry in values to execute script when users click the sanitized link.
DOMPurify before 3.4.16 XSS via IN_PLACE Returned Rawtext Root
DOMPurify before 3.4.16 contains a cross-site scripting vulnerability that allows attackers to bypass sanitization because IN_PLACE mode returns a force-removed style element whose text content still carries markup. Attackers can supply a style element containing a closing style tag and an img onerror payload, which executes script when the application serializes and re-parses the returned node.
DOMPurify before 3.4.13 Cross-Site Scripting via IN_PLACE hook
DOMPurify before 3.4.13 contains a cross-site scripting vulnerability in IN_PLACE sanitization where element-removal hooks fail to neutralize detached subtrees. Attackers can supply HTML with event handlers on descendant elements that execute after sanitization completes, even though the returned root appears clean.
DOMPurify before 3.4.12 Hook Bypass via CUSTOM_ELEMENT_HANDLING
DOMPurify before 3.4.12 fails to execute afterSanitizeElements hook for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck, allowing attributes to bypass application security policies. Attackers can preserve sensitive attributes on custom elements that later re-inject them into innerHTML sinks, creating second-order XSS gadgets.
DOMPurify before 3.4.9 Trusted Types Policy State Contamination
DOMPurify 3.0.0 before 3.4.9 does not reset the retained Trusted Types policy when clearConfig() is called, so a DOMPurify instance reused across trust boundaries stays bound to a previously supplied TRUSTED_TYPES_POLICY. A later caller that requests RETURN_TRUSTED_TYPE output receives a TrustedHTML object created by the old (potentially unsafe) policy rather than a clean default, which can lead to script execution at a Trusted Types sink. Passing TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy.
DOMPurify before 3.4.11 Permanent Attribute Allowlist Pollution via setConfig
DOMPurify before 3.4.11 fails to clone the ALLOWED_ATTR allowlist when setConfig() is used with an uponSanitizeAttribute hook, allowing the hook to permanently mutate the shared allowlist. Attackers can register a hook that conditionally allows dangerous attributes like onerror for trusted elements, then submit untrusted content that inherits the polluted allowlist and executes event handlers as stored XSS.