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 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 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 versions before 3.4.16 contain a cross-site scripting (XSS) vulnerability due to improper neutralization of input during web page generation. The vulnerability arises because the IN_PLACE mode returns a forcibly removed style element whose text content still includes markup, allowing attackers to inject malicious scripts. Specifically, attackers can craft a style element with a closing style tag and an img onerror payload that executes script when the application serializes and re-parses the node.
DOMPurify versions 3.4.13 through 3.4.15 contain a cross-site scripting (XSS) vulnerability due to improper neutralization of input during web page generation. The vulnerability arises because the IN_PLACE mode fails to neutralize subtrees detached by afterSanitizeElements or afterSanitizeAttributes hooks, allowing attackers to inject markup with event handlers that remain active in the live DOM. This can lead to script execution in the victim's origin.
DOMPurify versions before 3.4.13 contain a cross-site scripting (XSS) vulnerability in the IN_PLACE sanitization method. The vulnerability arises because element-removal hooks fail to neutralize detached subtrees, allowing attackers to inject HTML with event handlers on descendant elements that execute after sanitization. This occurs even though the returned root element appears clean after sanitization.
DOMPurify versions prior to 3.4.13 contain a vulnerability in the IN_PLACE sanitization mode where a hook that removes an element can leave detached descendant elements executable. This allows an attacker who can supply HTML to execute JavaScript via retained event handlers on detached subtrees after sanitization completes. The issue arises because the sanitization process skips neutralizing the subtree of a detached node when a hook removes it, leaving event handlers intact on disconnected elements.
DOMPurify versions before 3.4.12 have a vulnerability where the afterSanitizeElements hook is not executed for custom elements allowed via CUSTOM_ELEMENT_HANDLING.tagNameCheck. This allows attributes on these custom elements to bypass security policies, potentially enabling second-order cross-site scripting (XSS) attacks by preserving sensitive attributes that are later re-injected into innerHTML sinks.
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.3.2 contains a prototype pollution vulnerability in USE_PROFILES mode that allows attackers to bypass attribute filtering by polluting Array.prototype properties. Attackers can set Array.prototype properties like onclick to true, causing DOMPurify to accept event handlers as allowlisted attributes and resulting in DOM-based XSS when sanitized markup is rendered.
In DOMPurify through 3.3.3, function predicates supplied via ADD_ATTR or ADD_TAGS to DOMPurify.sanitize() persist in internal state (EXTRA_ELEMENT_HANDLING) across subsequent sanitize() calls on the same instance. If a later call on the same instance provides ADD_ATTR or ADD_TAGS as an array rather than a function, the previously set function handler is neither cleared nor overwritten, so it continues to approve attacker-controlled attributes or tags. This can allow dangerous event-handler attributes or forbidden tags (bypassing FORBID_TAGS) to survive sanitization, resulting in cross-site scripting. The vendor (Cure53) considers this an edge case outside DOMPurify's threat model; the referenced advisory lists 3.4.0 as the patched version.
DOMPurify through 3.3.3 fails to sanitize DOM elements passed via IN_PLACE mode when the element originates from a different window/realm (e.g., an iframe's contentDocument). A cross-realm instanceof check in the private _isNode() function returns false for foreign-realm nodes, causing DOMPurify to stringify the element (yielding '[object HTMLDivElement]'), silently reset IN_PLACE to false, and return the unsanitized element unchanged with any XSS payloads intact.
DOMPurify before 3.4.0 contains a logic error in the ADD_TAGS function where short-circuit evaluation allows forbidden tags to bypass FORBID_TAGS restrictions. Attackers can craft input containing tags listed in FORBID_TAGS that are also added via ADD_TAGS function, causing them to be retained in sanitized output.
DOMPurify before 3.4.7 (affected versions <= 3.4.5) passes direct references to the module-level DEFAULT_ALLOWED_TAGS and DEFAULT_ALLOWED_ATTR sets to the uponSanitizeElement and uponSanitizeAttribute hooks via data.allowedTags / data.allowedAttributes when sanitize is called without an explicit cfg.ALLOWED_TAGS / cfg.ALLOWED_ATTR array. A hook that mutates these fields permanently widens the default allow-lists for the lifetime of the DOMPurify instance, so all subsequent default-config sanitize calls inherit the widened defaults and attacker payloads using the poisoned tag/attribute name survive sanitization. removeAllHooks(), clearConfig(), and passing a fresh cfg do not recover the state; only constructing a new DOMPurify instance does.
DOMPurify versions >=3.0.0 and before 3.4.8, when configured with SAFE_FOR_TEMPLATES together with a DOM output mode (RETURN_DOM, RETURN_DOM_FRAGMENT, or IN_PLACE), fail to strip template expressions (e.g. ${evil}, {{evil}}, <%evil%>) inside <template> element content. The final normalization/scrub pass (_scrubTemplateExpressions) uses a NodeIterator and node.normalize() that do not descend into template.content, so expressions that only form after adjacent text nodes merge survive sanitization. This bypasses SAFE_FOR_TEMPLATES and can allow a downstream template engine to evaluate attacker-supplied expressions. The string output path is not affected.
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 3.4.11 has a hook-policy inconsistency involving the CUSTOM_ELEMENT_HANDLING configuration. Allowed custom elements bypass the afterSanitizeElements hook, which may cause sensitive attributes to be preserved on these elements while being removed from normal elements. This can lead to a second-order XSS vulnerability if the custom element later injects these attributes into an HTML sink such as innerHTML. This is not a direct DOMPurify XSS but a potential security policy bypass. A fix is available in versions 3.4.12 and later.
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.7, DOMPurify IN_PLACE sanitization could skip shadow contents attached to an element inside <template>.content, allowing attacker-controlled markup such as event handlers, JavaScript URLs, or scripts to survive and execute when an application cloned and inserted the sanitized template. This issue is fixed in version 3.4.7.
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(root, { IN_PLACE: true }) could preserve event-handler attributes on an attacker-controlled <form> root when a descendant name clobbered properties checked by _isClobbered, because _forceRemove no-opped on the parent-less root and _sanitizeAttributes returned early. This issue is fixed in version 3.4.6.
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.6, DOMPurify.sanitize(node, { IN_PLACE: true }) accepted same-origin foreign-realm DOM nodes while follow-on checks used parent-realm constructors, causing instanceof checks for forms, named node maps, document fragments, and elements to fail and skip clobber, template-content, and shadow-DOM sanitization branches so executable markup could survive. This issue is fixed in version 3.4.6.