GHSA-76mc-f452-cxcm

What it actually does

This vulnerability affects DOMPurify, an HTML sanitization library. In affected versions, custom hooks that mutate `data.allowedTags` or `data.allowedAttributes` can permanently alter DOMPurify’s default allowlists, polluting `DEFAULT_ALLOWED_TAGS` or `DEFAULT_ALLOWED_ATTR` for later sanitization operations. If an application uses such hooks, an attacker may be able to cause unsafe HTML tags or attributes to remain allowed across subsequent sanitization calls, potentially resulting in cross-site scripting (XSS). The impact is application-dependent and is most relevant where untrusted user-supplied HTML is sanitized and then rendered in a browser.

Why it matters to the business

Successful exploitation could allow attackers to run unauthorized JavaScript in users’ browsers, leading to account takeover, session theft, fraudulent actions, data exposure, or defacement in applications that render sanitized user content. Because DOMPurify is a widely used npm package and may be bundled into downstream web applications, exposure can exist both in direct dependencies and transitive/front-end build artifacts. The issue is not currently listed in CISA KEV, is not marked as ransomware-associated, and has no known public exploit maturity in the provided data, but it should still be remediated because XSS in user-facing applications can have high business impact.

How an attack unfolds

An attacker first identifies an application feature that accepts HTML or rich text and relies on DOMPurify for sanitization. Exploitation generally requires the application to use DOMPurify hooks that mutate `data.allowedTags` or `data.allowedAttributes`. The attacker submits crafted content that exercises the vulnerable hook behavior and causes the internal default allowlist to become polluted. After that pollution occurs, later sanitization operations may incorrectly preserve tags or attributes that should have been removed. The attacker then submits or causes another victim to view HTML containing script-capable constructs, such as event handler attributes, dangerous URL schemes, or otherwise unsafe markup. If the application renders the resulting sanitized output in a browser, attacker-controlled JavaScript may execute in the victim’s session.

How to fix it

Upgrade `dompurify` to version 3.4.7 or later. For npm-based projects, update direct dependency declarations and regenerate lockfiles, then rebuild and redeploy affected front-end or server-side bundles. Also review custom DOMPurify hooks and avoid mutating `data.allowedTags` or `data.allowedAttributes` directly; if customization is required, use safe configuration patterns, clone mutable structures before modification, and keep sanitizer configuration scoped to the intended call. As defense in depth, enforce a restrictive Content Security Policy, avoid rendering user HTML where possible, encode output by context, and ensure rich-text features only permit a minimal set of tags and attributes.

How to confirm the fix worked

Confirm the installed package version with dependency tooling such as `npm ls dompurify`, lockfile review, SBOM scanning, or software composition analysis, and verify that all deployed bundles contain DOMPurify 3.4.7 or later. Validate that no older bundled copies remain in compiled assets, container images, CDNs, or vendored JavaScript. Add a regression test that uses any application-defined DOMPurify hooks and verifies that changes to allowed tags or attributes do not persist across separate sanitization calls. Test representative rich-text inputs containing unsafe tags, event handlers, and dangerous URL schemes to confirm they are stripped after remediation.

Typical attack path

1. Find a web application feature that accepts and renders user-controlled HTML, rich text, comments, messages, profile content, documents, or CMS content.
2. Confirm or infer that the application uses a vulnerable DOMPurify version before 3.4.7.
3. Identify behavior suggesting the application uses custom DOMPurify hooks that modify allowed tags or attributes.
4. Submit crafted HTML that triggers mutation of `data.allowedTags` or `data.allowedAttributes` during sanitization.
5. Cause the polluted allowlist state to persist for subsequent sanitization calls.
6. Submit a second-stage payload containing markup or attributes that should normally be stripped.
7. Wait for a victim user or administrator to view the rendered content.
8. Execute JavaScript in the victim’s browser context and abuse that access to steal tokens, perform actions as the user, or access sensitive data available to the application.

How to detect it

There is no universal server-side indicator that this vulnerability was exploited, because successful XSS may execute entirely in a victim’s browser after malicious content is stored or reflected. Review application logs, WAF logs, reverse proxy logs, rich-text submission records, audit logs, and content databases for suspicious HTML submitted to fields that are later rendered. Focus on payloads containing script-capable tags, event handler attributes, SVG/MathML abuse, encoded JavaScript, `javascript:` URLs, or unusual attributes that should normally be removed by DOMPurify. Review Content Security Policy report endpoints for blocked inline script execution, blocked `javascript:` navigation, or unexpected script loads associated with pages that render user-generated HTML. In source code and built assets, search for custom `DOMPurify.addHook` logic that mutates `data.allowedTags` or `data.allowedAttributes`, as that pattern materially increases exploitability. Compare stored content before and after sanitization where available to identify unsafe tags or attributes that were unexpectedly preserved.

What your security team should do

• Prioritize upgrading all direct and transitive uses of `dompurify` to 3.4.7 or later, especially in internet-facing applications that render user-generated HTML.
• Inventory applications, packages, static bundles, and SBOMs for vulnerable DOMPurify versions, including vendored or bundled copies not visible as runtime npm dependencies.
• Review custom DOMPurify hook usage for direct mutation of `data.allowedTags` or `data.allowedAttributes`.
• Add security regression tests for sanitizer behavior across repeated calls to catch persistent allowlist pollution.
• Deploy or tighten Content Security Policy controls to reduce the impact of any remaining XSS path.
• Search stored user-generated content for unsafe HTML that may have bypassed sanitization before the upgrade.
• Monitor CSP violation reports, WAF events, and application logs for attempted XSS payloads targeting rich-text or HTML input fields.