GHSA-VXR8-FQ34-VVX9

Affected version

Tested against DOMPurify 3.4.8, repository commit 825e617753ac1169306a542d3174a77f717a0cf6.

Root cause

_parseConfig() overwrites trustedTypesPolicy when cfg.TRUSTED_TYPES_POLICY is truthy, but the default/null path only initializes the internal policy when trustedTypesPolicy === undefined. Once a custom policy has been set, later default config parsing leaves it in place.

Relevant code:

• src/purify.ts:786-812 accepts and stores cfg.TRUSTED_TYPES_POLICY.
• src/purify.ts:813-832 does not reset an existing policy when config has no policy or has TRUSTED_TYPES_POLICY: null.
• src/purify.ts:2123-2125 signs the final serialized HTML with the retained policy when RETURN_TRUSTED_TYPE is true.
• src/purify.ts:2133-2136 clearConfig() only clears CONFIG and SET_CONFIG; it does not reset trustedTypesPolicy or emptyHTML.

Local PoC

Run from the DOMPurify checkout, or set DOMPURIFY_REPO:

node /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js

Observed output:

{
  "result": {
    "baseline": "<b>baseline</b>",
    "duringPolicy": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterClearString": "<img src=\"x\">",
    "afterClearTrustedType": "[object TrustedHTML]",
    "afterClearTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterNullTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "mountedHTML": "<img src=\"x\" onerror=\"alert(&quot;TT_POLICY_SURVIVED_CLEARCONFIG&quot;)\">"
  },
  "dialogs": [
    "TT_POLICY_SURVIVED_CLEARCONFIG"
  ]
}

The important part is the split behavior after cleanup:

• purify.clearConfig(); purify.sanitize(...); returns a normal sanitized string (<img src="x">), because the later call is not asking for a Trusted Type.
• purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true }); still uses the old policy and returns attacker-controlled TrustedHTML.
• Passing { TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true } also still returns attacker-controlled TrustedHTML.

Preconditions

This is a shared-instance state contamination issue. It matters when one DOMPurify instance is reused by multiple integrations, plugins, request handlers, or components with different trust levels, and a cleanup step relies on clearConfig() to restore safe defaults.

This is not a default string-input bypass. An attacker must be able to influence a prior TRUSTED_TYPES_POLICY on the reused instance, or a less-trusted integration must have installed an unsafe policy.

Severity

impact is XSS at a Trusted Types sink in applications that reuse a DOMPurify instance across trust boundaries. Attack complexity is high because exploitation depends on prior policy injection or a less-trusted integration and a later RETURN_TRUSTED_TYPE sink.

A DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied TRUSTED_TYPES_POLICY even after clearConfig() is called. A later caller that requests RETURN_TRUSTED_TYPE receives a TrustedHTML object created by the old policy, not by a clean default configuration.

If the old policy is unsafe or controlled by a less-trusted integration, this turns a later "default" sanitize call into script execution at a Trusted Types sink. TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy.
dompurify-trusted-types-policy-survives-clearconfig-poc.js

Kodem intelligence

Make clearConfig() reset Trusted Types state as part of restoring defaults, or have _parseConfig() explicitly clear trustedTypesPolicy and emptyHTML when TRUSTED_TYPES_POLICY: null is supplied.

1. What is GHSA-VXR8-FQ34-VVX9? GHSA-VXR8-FQ34-VVX9 is a low-severity security vulnerability in dompurify (npm), affecting versions < 3.4.9. It is fixed in 3.4.9.
2. Which versions of dompurify are affected by GHSA-VXR8-FQ34-VVX9? dompurify (npm) versions < 3.4.9 is affected.
3. Is there a fix for GHSA-VXR8-FQ34-VVX9? Yes. GHSA-VXR8-FQ34-VVX9 is fixed in 3.4.9. Upgrade to this version or later.
4. Is GHSA-VXR8-FQ34-VVX9 exploitable, and should I be worried? Whether GHSA-VXR8-FQ34-VVX9 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-VXR8-FQ34-VVX9 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-VXR8-FQ34-VVX9? Upgrade dompurify to 3.4.9 or later.