GHSA-vxr8-fq34-vvx9

What it actually does

DOMPurify is affected by a cross-site scripting class flaw involving Trusted Types state management. A Trusted Types policy can survive a call to clearConfig(), allowing a previously configured or attacker-influenced policy to affect later sanitization operations that use RETURN_TRUSTED_TYPE. In applications that rely on DOMPurify to produce TrustedHTML or other Trusted Types-safe output, this stale policy behavior can cause later sanitization results to be generated under unintended assumptions, potentially enabling sanitized output to be poisoned and unsafe HTML or script-capable content to reach DOM sinks.

Why it matters to the business

Applications using affected DOMPurify versions may incorrectly trust content that should have been sanitized, creating a path for browser-side code execution in users’ sessions. The likely business consequences include account takeover risk where session-bearing pages are affected, unauthorized actions performed as users, data exposure through the browser, defacement or phishing within trusted application pages, and loss of confidence in web application integrity. The package is widely used in web front ends and downstream libraries, so exposure may exist both through direct dependency use and transitive dependency chains.

How an attack unfolds

An attacker first needs a path to influence HTML or markup that the application later sanitizes with DOMPurify and inserts into a page. The vulnerable condition depends on application usage of DOMPurify configuration, specifically interactions involving Trusted Types, RETURN_TRUSTED_TYPE, and clearConfig(). If an attacker can cause or benefit from a Trusted Types policy that persists after configuration is cleared, later calls that expect a clean configuration may return trusted output under the stale policy. The attacker then supplies crafted markup designed to pass through the flawed sanitization flow and be inserted into a sensitive DOM sink. Once a victim views the affected page or content, the browser interprets the resulting HTML in the application’s origin, enabling script execution or equivalent DOM-based abuse. There is no known public exploitation maturity reported for this advisory, and it is not listed in CISA KEV, but the impact is meaningful for applications that rely on Trusted Types as part of their XSS defense model.

How to fix it

Upgrade dompurify to version 3.4.9 or later wherever it is used. Update direct npm dependencies and regenerate lockfiles so deployed builds do not continue to bundle an affected version. Also inspect transitive dependencies that bundle or pin DOMPurify and update the parent package if needed. As defense in depth, avoid relying on client-side sanitization alone for untrusted content, keep DOMPurify configuration explicit per sanitization call where possible, avoid unsafe post-sanitization HTML manipulation, enforce a strict Content Security Policy with Trusted Types, and review code paths that call clearConfig(), setConfig(), addHook(), removeHook(), or use RETURN_TRUSTED_TYPE. If immediate upgrade is not possible, remove use of the affected Trusted Types return mode or isolate sanitizer instances so attacker-influenced configuration state cannot affect later sanitization operations.

How to confirm the fix worked

Confirm the installed and bundled DOMPurify version is 3.4.9 or later. Check package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls dompurify, yarn why dompurify, or pnpm why dompurify, and verify production build artifacts do not include an older bundled copy. Review application code for DOMPurify.clearConfig(), DOMPurify.setConfig(), DOMPurify.sanitize(...RETURN_TRUSTED_TYPE...), and Trusted Types policy creation. Add regression tests that call clearConfig() after Trusted Types policy setup and verify subsequent RETURN_TRUSTED_TYPE sanitization cannot be affected by stale policy state. Validate that sanitized attacker-controlled HTML is not inserted with innerHTML, outerHTML, insertAdjacentHTML, document.write, or equivalent sinks without appropriate controls.

Typical attack path

1. Identify a web application using a vulnerable DOMPurify version before 3.4.9.
2. Find a feature that accepts user-controlled HTML, rich text, Markdown-rendered content, comments, profile fields, messages, or uploaded content that is sanitized client-side or server-side with DOMPurify.
3. Determine whether the application uses Trusted Types-related DOMPurify options, especially RETURN_TRUSTED_TYPE, and resets sanitizer configuration with clearConfig().
4. Trigger or rely on a sanitizer state sequence where a Trusted Types policy remains active after clearConfig().
5. Submit crafted markup that is transformed into trusted output under the unintended stale policy behavior.
6. Cause the application to place the resulting content into a browser DOM sink in a victim’s session.
7. Execute JavaScript or DOM actions in the context of the vulnerable application, potentially stealing data, performing user actions, or injecting phishing content.

How to detect it

To determine whether exploitation already occurred, review application, CDN, WAF, and reverse-proxy logs for stored or reflected HTML payload submissions to rich-text or user-content endpoints, especially payloads later rendered to other users. Inspect client-side error telemetry, CSP violation reports, and browser monitoring for blocked inline script execution, Trusted Types violations, unexpected DOM sink usage, or sudden spikes in script errors on pages rendering user-controlled content. Search content stores and moderation queues for suspicious HTML using event handlers, script-capable SVG/MathML, javascript: URLs, iframe/object/embed tags, encoded payloads, or DOM clobbering patterns. Review source control and build artifacts to identify whether affected DOMPurify versions were deployed during the relevant period. Because this flaw is a library behavior issue rather than a network-exposed service vulnerability, there are no universal exploitation log lines; detection must focus on suspicious content inputs, browser security reports, and evidence of unauthorized browser-side actions such as anomalous account changes, token misuse, unexpected redirects, or user-reported page manipulation.

• DOMPurify.clearConfig(
• RETURN_TRUSTED_TYPE
• trustedTypes.createPolicy
• <script
• </script>
• onerror=
• onload=
• onclick=
• onmouseover=
• javascript:
• data:text/html
• <svg
• <math
• <iframe
• <object
• <embed
• srcdoc=
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• new Function(
• innerHTML
• outerHTML
• insertAdjacentHTML
• document.write

What your security team should do

• Prioritize upgrading all direct DOMPurify npm usage to 3.4.9 or later and redeploy affected web assets.
• Run dependency inventory and software composition analysis to identify transitive or bundled DOMPurify copies in front-end applications, component libraries, CMS plugins, and rich-text features.
• Search source code for DOMPurify Trusted Types usage, especially RETURN_TRUSTED_TYPE combined with clearConfig(), and prioritize those applications for review.
• Add or update unit and browser security tests covering sanitizer reset behavior and untrusted rich-text rendering paths.
• Strengthen browser-side mitigations with a restrictive Content Security Policy and Trusted Types enforcement, while ensuring policies are narrowly scoped and not overly permissive.
• Monitor user-generated content features for suspicious HTML payloads and investigate reports of unexpected popups, redirects, page defacement, or unauthorized user actions.
• If third-party libraries bundle DOMPurify, upgrade the parent library or override/resolution-pin DOMPurify to a fixed version where compatible.