Dompurify

IN_PLACE sanitization bypass in DOMPurify before 3.4.13 enables persistent cross-site scripting after sanitize() returns, affecting any application that uses DOMPurify's documented element-removal hook pattern with IN_PLACE mode enabled. When a uponSanitizeElement or beforeSanitizeElements hook removes a node via node.remove(), DOMPurify's _sanitizeElements() exits that node's processing branch without invoking _neutralizeSubtree(), leaving descendant elements - including those carrying browser-queued event handlers such as img onload - outside both the returned DOM and the DOMPurify.removed list. A working proof-of-concept targeting DOMPurify 3.4.12 under Chromium is published in the official GHSA advisory; no active exploitation is confirmed in CISA KEV at time of analysis.

DOMPurify before 3.4.12 fails to invoke the afterSanitizeElements hook for custom elements permitted via CUSTOM_ELEMENT_HANDLING.tagNameCheck, enabling attackers to retain

Mutation-XSS in DOMPurify before 3.3.2 enables JavaScript execution in victim browsers when sanitized output is re-inserted into the DOM via innerHTML using wrapper elements such as xmp, noscript, iframe, noembed, noframes, or script. Attacker-controlled payloads containing wrapper-closing sequences (e.g., </xmp>) survive DOMPurify sanitization intact but mutate during the browser's second parse, breaking out of the wrapper context and activating injected event handlers. A working public proof-of-concept is confirmed in the GHSA advisory; no CISA KEV listing at time of analysis.

Prototype pollution in DOMPurify's USE_PROFILES mode enables DOM-based XSS by causing the sanitizer to accept event handler attributes it should block. Versions up to and including 3.3.1 of the npm package rebuild ALLOWED_ATTR as a plain JavaScript array when USE_PROFILES is active, making attribute allowlist lookups traverse the prototype chain - so a polluted Array.prototype (e.g., Array.prototype.onclick = true) causes DOMPurify to silently pass through event handlers like onclick into sanitized output. A proof-of-concept is included in the vendor advisory GHSA-cj63-jhhr-wcxv; no CISA KEV listing has been identified, indicating no confirmed active exploitation at time of analysis.

URI validation bypass in DOMPurify 3.3.1 and earlier allows `javascript:` protocol payloads to survive HTML sanitization and execute as DOM-based XSS when a crafted link is activated. The flaw exists in the `_isValidAttribute` function, which short-circuits before URI-safe validation runs when a caller-supplied predicate via `EXTRA_ELEMENT_HANDLING.attributeCheck` returns `true` for a given attribute/tag pair. Exploitation is conditioned on the consuming application using the non-default `ADD_ATTR` predicate API, but a working proof-of-concept is confirmed in the official GHSA advisory; no CISA KEV listing is present at time of analysis.

DOMPurify through 3.3.3 leaks function predicate state across sanitize() calls on the same instance, enabling XSS bypass when applications invoke the library with mixed parameter types for ADD_ATTR or ADD_TAGS. Specifically, a function predicate supplied to one sanitize() call persists in the internal EXTRA_ELEMENT_HANDLING map and is not evicted when a subsequent call on the same instance supplies ADD_ATTR or ADD_TAGS as a plain array, allowing attacker-controlled event-handler attributes or vendor-forbidden tags to survive sanitization. No public exploit or CISA KEV listing is confirmed at time of analysis; the CVSS 4.0 score of 5.1 reflects user interaction required and impact scoped to the subsequent system (browser context), consistent with a reflected or stored XSS consequence.

DOMPurify's IN_PLACE sanitization mode silently bypasses XSS filtering when processing DOM elements sourced from a different JavaScript window context (e.g., an iframe's contentDocument), returning the unsanitized element - payloads intact - to the calling application. The private _isNode() function's instanceof check fails for foreign-realm nodes because prototype chains belong to distinct window objects, causing DOMPurify to misidentify the input, disable IN_PLACE mode silently, and pass through unfiltered content. The vendor has explicitly declined to issue a fix, categorizing this as outside DOMPurify's threat model, leaving all versions through 3.3.3 permanently exposed without a vendor-supplied remediation path.

DOMPurify versions up to and including 3.3.3 incorrectly resolves a tag-allow conflict when ADD_TAGS is used in its function form alongside FORBID_TAGS, causing forbidden tags to survive sanitization. The flaw is a short-circuit evaluation error in purify.ts (lines 1117-1123): when the ADD_TAGS callback (tagCheck) returns true for a tag, the Boolean AND short-circuits, meaning FORBID_TAGS is never consulted - directly contradicting the attribute-side behavior where FORBID_ATTR always wins. An attacker who can supply HTML to an application using this specific configuration can inject tags the developer explicitly intended to block, leading to XSS or related injection in whatever context the sanitized output is rendered. No public exploit code has been identified and the vulnerability is not listed in CISA KEV at time of analysis.

Hook mutation pollution in DOMPurify <= 3.4.5 allows persistent bypass of HTML sanitization defaults when application-installed hooks mutate data.allowedTags or data.allowedAttributes. Because these hook fields are direct references to the library's live DEFAULT_ALLOWED_TAGS and DEFAULT_ALLOWED_ATTR sets rather than copies, any write inside a uponSanitizeElement or uponSanitizeAttribute hook permanently widens the global allow-lists for the entire lifetime of the DOMPurify instance - meaning all subsequent sanitize() calls under default config will pass through attacker-controlled HTML using the poisoned tag or attribute name. No public exploit has been identified at time of analysis, and this vulnerability is not listed in CISA KEV; real-world risk is gated on the presence of the specific hook mutation pattern in the target application.

Cross-site scripting in DOMPurify 3.4.6 and earlier enables script execution when the library's IN_PLACE sanitization mode processes attacker-supplied live DOM nodes whose nodeName property has been clobbered to masquerade as an allowed element. The vulnerability bypasses DOMPurify's existing clobbering protections, which were scoped only to form elements, leaving all other live non-form nodes susceptible to nodeName manipulation. No vendor-released patch exists at time of analysis; no public exploit code has been identified, though the GHSA advisory provides a detailed technical breakdown sufficient for exploit construction.

SAFE_FOR_TEMPLATES bypass in DOMPurify 3.0.0-3.4.7 allows template expressions such as ${evil}, {{evil}}, and <%evil%> to survive sanitization when DOM output modes (RETURN_DOM, RETURN_DOM_FRAGMENT, or IN_PLACE) are used alongside SAFE_FOR_TEMPLATES: true. The final normalization pass (_scrubTemplateExpressions) employs a NodeIterator that, per DOM specification, does not descend into <template>.content - a separate DocumentFragment outside the normal child-node tree - meaning split text nodes that merge into exploitable expressions inside template content are never caught. Downstream template engines receiving this output may evaluate attacker-supplied expressions, producing XSS or template injection outcomes; no public exploit is identified at time of analysis, and the string output path is explicitly confirmed unaffected.

Trusted Types policy state contamination in DOMPurify 3.0.0-3.4.8 allows a previously supplied TRUSTED_TYPES_POLICY to survive a clearConfig() call, poisoning subsequent sanitize() calls that request RETURN_TRUSTED_TYPE output. Any application that reuses a single DOMPurify instance across trust boundaries - where one integration sets a permissive or attacker-influenced TRUSTED_TYPES_POLICY and a later caller invokes clearConfig() expecting a clean slate - will receive a TrustedHTML object signed by the old policy, potentially enabling script execution at a Trusted Types sink. A public proof-of-concept is attached to the GHSA advisory; exploitation is not confirmed in CISA KEV.

Stored XSS is achievable in applications using DOMPurify's setConfig() API combined with an uponSanitizeAttribute hook that conditionally permits dangerous attributes for trusted elements. The 3.4.7 patch introduced a clone-guard to prevent hook-driven allowlist mutation, but that guard lives exclusively inside _parseConfig(); setConfig() sets an internal SET_CONFIG flag that causes sanitize() to skip _parseConfig() entirely, handing hooks the live shared ALLOWED_ATTR object. One trusted render permanently poisons the allowlist for the entire DOMPurify instance lifetime, so subsequent attacker-controlled content inherits the mutated policy and retains event-handler attributes like onerror or onclick unstripped. No public exploit or CISA KEV listing has been identified at time of analysis; the CVSS 4.0 score of 5.1 reflects that exploitation requires prior privilege to trigger hook pollution and passive victim interaction to realize the XSS.

DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. [CVSS 6.1 MEDIUM]

DOMPurify before 3.2.4 has an incorrect template literal regular expression, sometimes leading to mutation cross-site scripting (mXSS). Rated medium severity (CVSS 4.5), this vulnerability is no authentication required. Public exploit code available.

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Improperly Controlled Modification of Object Prototype Attributes (Prototype Pollution) vulnerability could allow attackers to modify object prototypes to inject properties affecting application logic.

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.

DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity.

Cure53 DOMPurify before 2.0.17 allows mutation XSS. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.

DOMPurify before 2.0.1 allows XSS because of innerHTML mutation XSS (mXSS) for an SVG element or a MATH element, as demonstrated by Chrome and Safari. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.