GHSA-cmwh-pvxp-8882

What it actually does

DOMPurify is a client-side/server-side HTML sanitization library used to remove dangerous markup before rendering user-controlled HTML. This flaw allows configuration state pollution through setConfig(), specifically permanent modification of ALLOWED_ATTR despite prior protections intended to prevent hook-based pollution. If an application sanitizes attacker-controlled HTML with a polluted DOMPurify configuration, attributes that should normally be stripped may remain in sanitized output. Depending on the application’s rendering context and allowed tags, this can undermine the sanitizer’s security boundary and enable cross-site scripting or HTML injection.

Why it matters to the business

Applications that rely on DOMPurify to safely display user-generated or externally supplied HTML may unintentionally render unsafe content. Successful exploitation can allow attackers to run JavaScript in a victim’s browser, steal session tokens or sensitive page data, perform actions as the victim, modify page content, or pivot into account takeover workflows. The issue is not listed in CISA KEV and no public exploit maturity is reported, but DOMPurify is widely used across web applications, so affected packages should still be upgraded promptly, especially in products that process rich text, comments, messages, profile fields, CMS content, or imported HTML.

How an attack unfolds

An attacker first identifies an application feature that accepts or processes HTML and relies on DOMPurify for sanitization. The attacker then looks for a code path where DOMPurify.setConfig() is invoked with attacker-influenced configuration or where untrusted code can affect sanitizer configuration. By abusing the flaw, the attacker causes ALLOWED_ATTR to be permanently polluted so that unsafe or unexpected attributes remain allowed across subsequent sanitization operations. The attacker then submits crafted HTML containing attributes that would normally be removed but are now preserved. When another user or administrator views the sanitized content, the browser interprets the preserved markup in a dangerous context, potentially executing attacker-controlled script or enabling DOM manipulation. Because the pollution can be persistent within the runtime, later sanitization calls may remain weakened until the process, page, or application context is reset.

How to fix it

Upgrade DOMPurify to version 3.4.11 or later for npm-based deployments. Audit package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled frontend assets to ensure no vulnerable DOMPurify copy remains through direct or transitive dependencies. Avoid allowing untrusted input to influence DOMPurify.setConfig(), ALLOWED_ATTR, hooks, profiles, or other sanitizer policy controls. Prefer immutable, centrally defined sanitizer configurations and create isolated sanitizer instances where supported. Treat DOMPurify as a defense-in-depth control: continue to use contextual output encoding, strict Content Security Policy, HttpOnly/SameSite cookies, and server-side validation where applicable. If immediate upgrade is not possible, remove attacker influence over sanitizer configuration, restart long-lived processes or browser contexts that may retain polluted state, and restrict rich HTML rendering until patched.

How to confirm the fix worked

Confirm the installed package version is DOMPurify 3.4.11 or later using the package manager and lockfiles, for example npm ls dompurify, npm audit, yarn why dompurify, or pnpm why dompurify. Verify production bundles were rebuilt and redeployed after the dependency update; frontend lockfile updates alone are not sufficient if old JavaScript assets remain cached or served by a CDN. Review application code for calls to DOMPurify.setConfig(), addHook(), ALLOWED_ATTR, USE_PROFILES, and custom sanitization wrappers, and confirm no untrusted data can alter sanitizer policy. Regression-test rich text and HTML-rendering workflows with known XSS payloads and confirm dangerous attributes are removed. Where feasible, add unit tests that assert sanitizer configuration cannot be mutated by user-controlled input and that subsequent sanitize() calls retain the expected allowlist.

Typical attack path

1. Identify an application endpoint or UI feature that accepts rich text, HTML, Markdown-to-HTML, pasted content, email content, comments, messages, profile fields, or CMS entries.
2. Determine that the application uses a vulnerable DOMPurify npm version before 3.4.11.
3. Find a path that invokes DOMPurify.setConfig() or otherwise permits attacker-influenced sanitizer configuration.
4. Trigger configuration pollution so ALLOWED_ATTR is permanently expanded or modified.
5. Submit HTML containing attributes that should normally be stripped by DOMPurify.
6. Wait for the poisoned content to be rendered to another user, administrator, or automated browser process.
7. Execute JavaScript or abuse preserved HTML attributes to steal data, perform actions in the victim’s session, or alter displayed content.

How to detect it

Detecting confirmed exploitation is difficult because the vulnerability affects sanitizer behavior and the final payload may execute in a victim’s browser without producing a server-side error. Start with dependency and code review to identify exposure: vulnerable DOMPurify versions before 3.4.11, use of DOMPurify.setConfig(), and any user-influenced sanitizer configuration. For retrospective exploitation hunting, review application logs, API request bodies, WAF events, CDN logs, and stored content repositories for rich-text fields containing suspicious HTML attributes, event handlers, SVG/MathML payloads, JavaScript URLs, encoded script content, or unusual sanitizer configuration values such as ALLOWED_ATTR. Review browser-side telemetry, CSP violation reports, RUM/error logs, and frontend exception logs for script execution attempts originating from user-generated content pages. If the application stores sanitized HTML, compare historical stored content against the expected DOMPurify policy and flag records containing attributes that should not be allowed. Investigate any sequence where a user submits suspicious rich HTML followed by administrator or high-privilege user access to that content, unexpected account actions, session anomalies, or CSP violations.

• DOMPurify.setConfig(
• ALLOWED_ATTR
• ADD_ATTR
• addHook(
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• javascript:
• data:text/html
• <svg
• <math
• <iframe
• <object
• <embed
• srcdoc=
• xlink:href=
• <img src=x onerror=
• <svg/onload=
• autofocus onfocus=
• style=animation-name
• script-src-elem
• violated-directive

What your security team should do

• Inventory all applications and build artifacts using the dompurify npm package and prioritize internet-facing, multi-user, CMS, messaging, ticketing, collaboration, and admin-console applications.
• Upgrade DOMPurify to 3.4.11 or later and redeploy rebuilt frontend/server bundles.
• Search source code for DOMPurify.setConfig(), ALLOWED_ATTR, ADD_ATTR, addHook(), and custom sanitizer wrappers; remove any user-controlled influence over sanitizer configuration.
• Review stored rich-text content submitted since the vulnerable version was deployed for suspicious attributes or script-like payloads.
• Enable or tighten Content Security Policy to reduce the impact of any sanitizer bypass, ideally avoiding unsafe-inline and restricting script-src to trusted origins with nonces or hashes.
• Invalidate or refresh cached JavaScript assets after patching so clients do not continue using vulnerable bundled DOMPurify code.
• Monitor web, API, WAF, and application logs for attempted XSS payloads in fields that accept HTML or rich text.
• If suspicious exploitation is found, investigate affected user sessions, administrative actions performed after viewing attacker-controlled content, and any credential or token exposure paths.