GHSA-cj63-jhhr-wcxv

What it actually does

DOMPurify versions before 3.3.2 can be affected by prototype pollution involving the USE_PROFILES configuration. If attacker-controlled input can influence JavaScript object properties or sanitizer configuration, polluted prototype values may cause DOMPurify to treat unsafe attributes as allowed. In practical terms, HTML that should have had event-handler attributes removed, such as onload, onerror, onclick, or similar JavaScript-bearing attributes, may remain in sanitized output, enabling cross-site scripting in applications that render the sanitized HTML in a browser.

Why it matters to the business

Applications relying on affected DOMPurify versions to safely render user-supplied HTML may expose users to script execution in their browsers. Successful exploitation can lead to account takeover, session theft where cookies or tokens are accessible to JavaScript, fraudulent actions performed as the victim, data exposure, defacement, or phishing inside a trusted application. The issue affects a common npm security library, so downstream exposure can be broad where DOMPurify is bundled directly or through front-end dependencies.

How an attack unfolds

An attacker first identifies an application path that accepts or stores HTML, rich text, markdown-rendered HTML, profile content, comments, messages, templates, or other browser-rendered content that is sanitized using a vulnerable DOMPurify version. The attacker then looks for a way to introduce prototype pollution, commonly by submitting JSON, query parameters, form fields, or nested object data containing properties such as __proto__, constructor, or prototype. If that polluted state influences DOMPurify configuration, particularly USE_PROFILES or related allow-list behavior, the sanitizer may fail to strip unsafe event-handler attributes. The attacker then submits HTML containing an executable event handler, such as an image with an onerror handler or an SVG/body element with an onload handler. When another user or an administrator views the sanitized content, the browser executes the attacker-controlled JavaScript in the context of the vulnerable application.

How to fix it

Upgrade DOMPurify to version 3.3.2 or later. For npm-based projects, update the direct dependency and regenerate the lockfile so deployed builds resolve to the fixed version. If DOMPurify is included transitively, update the parent package or use package manager overrides/resolutions to force dompurify >= 3.3.2. Rebuild and redeploy front-end bundles, server-side rendering services, and any packaged assets that include DOMPurify. As defense in depth, prevent prototype pollution by rejecting or safely handling object keys such as __proto__, prototype, and constructor; avoid merging untrusted objects into sanitizer configuration; create sanitizer configuration from trusted constants only; use null-prototype objects where appropriate; and enforce a Content Security Policy that limits inline script execution. If immediate upgrade is not possible, block user-supplied event-handler attributes at an additional validation layer and disable rendering of untrusted HTML until the dependency is fixed.

How to confirm the fix worked

Confirm that all runtime and bundled copies of DOMPurify resolve to 3.3.2 or later. Check package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and built JavaScript bundles for older dompurify versions. Run dependency scanners such as npm audit, osv-scanner, Snyk, or equivalent SCA tooling after the upgrade. Add regression tests that sanitize HTML containing event handlers and verify the output removes attributes such as onerror, onload, onclick, onmouseover, and onanimationstart even when objects containing __proto__, constructor, or prototype keys are processed before sanitization. Validate in a browser or DOM-capable test environment that sanitized output does not execute JavaScript.

Typical attack path

1. Find an application feature that accepts user-controlled HTML or rich text and later renders it in a browser.
2. Confirm that the application uses a vulnerable DOMPurify release before 3.3.2, either directly or through bundled front-end code.
3. Identify an input path that can pollute JavaScript object prototypes or influence sanitizer configuration objects.
4. Submit a pollution payload using keys such as __proto__, constructor, or prototype to manipulate sanitizer-related behavior such as USE_PROFILES.
5. Submit HTML containing normally blocked event-handler attributes such as onerror, onload, onclick, or onmouseover.
6. Trigger rendering of the sanitized content in a victim browser.
7. Execute JavaScript in the victim session to steal data, perform actions, redirect the user, or establish persistence in stored content.

How to detect it

To determine whether exploitation has already occurred, review web access logs, API gateway logs, WAF logs, application logs, and stored user-generated content for prototype pollution keys combined with HTML event-handler payloads. Focus on endpoints that accept JSON, rich text, markdown, comments, messages, profile fields, templates, CMS content, or HTML fragments. Look for requests containing __proto__, constructor.prototype, prototype, or nested object notation combined with USE_PROFILES or suspicious event-handler attributes. Inspect rendered or stored content for tags carrying onerror, onload, onclick, onmouseover, onfocus, onanimationstart, or similar attributes that should normally be removed by DOMPurify. Review browser-side telemetry, CSP violation reports, EDR browser event logs, and application error monitoring for unexpected inline script execution, outbound requests to unfamiliar domains, token exfiltration patterns, or JavaScript execution from user-controlled content. Because this is a client-side injection issue, server logs may show only the content submission and subsequent victims viewing it; correlate suspicious content creation with later account actions, privilege changes, data exports, or unusual navigation by users who viewed that content.

• __proto__
• constructor.prototype
• prototype[
• USE_PROFILES
• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onanimationstart=
• <img src=x onerror=
• <svg onload=
• <body onload=
• javascript:
• dompurify@3.3.1
• dompurify@3.3.0

What your security team should do

• Prioritize upgrading all dompurify npm dependencies to 3.3.2 or later, especially in applications that render user-generated HTML or rich text.
• Search source code and dependency lockfiles for direct or transitive DOMPurify versions below 3.3.2 and ensure rebuilt artifacts no longer contain vulnerable bundled code.
• Review application code for unsafe object merges involving untrusted JSON, query parameters, request bodies, or form data, especially near sanitizer configuration creation.
• Add or strengthen server-side and client-side validation that rejects prototype pollution keys such as __proto__, constructor, and prototype in untrusted structured input.
• Deploy or tighten Content Security Policy controls to reduce the impact of any remaining script injection path.
• Hunt historical logs and stored user content for prototype pollution attempts and HTML event-handler payloads.
• Add automated tests to ensure DOMPurify strips dangerous event handlers under polluted-object conditions.
• If the application supports stored rich-text content, consider re-sanitizing previously stored content after the upgrade before it is rendered again.