GHSA-cjmm-f4jc-qw8r

What it actually does

DOMPurify versions before 3.3.2 can fail to apply URI-safety checks when an application uses an ADD_ATTR predicate function to allow additional HTML attributes. If that predicate permits a URL-bearing attribute, attacker-controlled markup may retain dangerous URI schemes such as javascript: or other executable/navigation payloads that would normally be stripped. The result is a sanitizer bypass that can lead to cross-site scripting when the sanitized output is inserted into a page.

Why it matters to the business

Applications that rely on DOMPurify to safely render user-supplied HTML may unintentionally expose users to script execution, account actions performed in the user’s browser, session theft depending on cookie protections, phishing overlays, or unauthorized data access within the affected web application. Because DOMPurify is widely used as a dependency in web front ends and downstream packages, exposure may exist both in direct application code and in components that sanitize rich text, comments, messages, CMS content, or previews.

How an attack unfolds

An attacker first identifies a feature that accepts HTML or rich text and later renders sanitized content in a browser. The vulnerable condition depends on the application configuring DOMPurify with ADD_ATTR as a predicate function rather than only relying on default attribute handling. The attacker submits crafted markup containing an attribute that the predicate allows and whose value contains a dangerous URI or browser-executable payload. Due to the flaw, DOMPurify may preserve that attribute without applying the normal URI validation rules. When another user views or interacts with the rendered content, the browser interprets the retained payload, resulting in cross-site scripting in the security context of the affected application.

How to fix it

Upgrade DOMPurify to version 3.3.2 or later. For npm-based projects, update the direct dependency and regenerate lockfiles so deployed builds resolve to the fixed version: dompurify 3.3.2 or later. Also audit custom sanitizer configuration, especially ADD_ATTR predicate functions, and avoid permitting URL-bearing attributes unless they are strictly required and separately validated. Where feasible, prefer DOMPurify defaults for URI-sensitive attributes, restrict allowed schemes to http and https, and deploy defense-in-depth controls such as a strict Content Security Policy that blocks inline script and javascript: navigation.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles resolve DOMPurify to 3.3.2 or later, including transitive copies bundled by front-end packages. Run package inventory commands such as npm ls dompurify, npm audit, or software composition analysis tooling against the built artifact as well as source repositories. Review sanitizer configuration for ADD_ATTR functions and test representative payloads containing dangerous URI schemes in allowed attributes; the fixed behavior should remove or neutralize unsafe URI values. Validate the production bundle or container image, not only the development branch, to ensure the upgraded dependency is actually deployed.

Typical attack path

1. Find a user-controlled HTML input or rich-text rendering feature protected by DOMPurify.
2. Determine or infer that the application uses a custom ADD_ATTR predicate to allow additional attributes.
3. Craft HTML containing a predicate-allowed URI-bearing attribute with a dangerous value such as a javascript: URL.
4. Submit the payload through the vulnerable feature so it is stored or reflected after sanitization.
5. Trigger rendering of the sanitized output in a victim’s browser.
6. Use the resulting script execution to steal page data, perform actions as the victim, redirect the user, or stage further browser-side attacks.

How to detect it

To assess prior exploitation, focus on locations where user-supplied HTML is accepted, stored, sanitized, and rendered. Review application logs, content moderation records, database exports of user-generated HTML, web access logs around rich-text submission endpoints, and client-side error or security telemetry. Look for submitted markup containing dangerous URI schemes inside attributes that are unusual for the application, especially near features using custom DOMPurify ADD_ATTR logic. Investigate reports of unexpected redirects, pop-ups, credential prompts, unauthorized user actions following content views, or Content Security Policy violation reports showing blocked javascript: execution. If CSP reporting is enabled, search reports for blocked-uri values involving javascript:, data:, or inline script triggered from pages that render user-generated content. Because exploitation payloads are application-specific and may be stored rather than visible in network logs, forensic review of persisted user content is often more reliable than perimeter telemetry alone.

• ADD_ATTR
• DOMPurify.sanitize
• javascript:
• java\u0000script:
• javascript:
• data:text/html
• data:image/svg+xml
• vbscript:
• xlink:href="javascript:
• href="javascript:
• src="javascript:
• formaction="javascript:
• action="javascript:
• srcdoc=
• onerror=
• onload=
• <svg
• <math
• blocked-uri: javascript:
• violated-directive: script-src

What your security team should do

• Inventory all applications and front-end packages that include DOMPurify, including transitive and bundled copies.
• Prioritize upgrades for applications that render user-supplied HTML, rich text, comments, messages, profile content, CMS content, or previews.
• Upgrade dompurify to 3.3.2 or later and redeploy affected client-side or server-side rendering components.
• Search codebases for DOMPurify configurations using ADD_ATTR predicate functions and review whether they allow URL-bearing attributes.
• Add regression tests for sanitizer bypass payloads using javascript:, data:, vbscript:, and encoded URI variants in custom allowed attributes.
• Use Content Security Policy as a compensating control, especially script-src without unsafe-inline and restrictions that reduce the impact of javascript: URL execution.
• Review historical submitted HTML content for suspicious URI-bearing attributes if vulnerable rendering paths were exposed to untrusted users.