DOMPurify 3.0.0 before 3.4.9 does not reset the retained Trusted Types policy when clearConfig() is called, so a DOMPurify instance reused across trust boundaries stays bound to a previously supplied TRUSTED_TYPES_POLICY. A later caller that requests RETURN_TRUSTED_TYPE output receives a TrustedHTML object created by the old (potentially unsafe) policy rather than a clean default, which can lead to script execution at a Trusted Types sink. Passing TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy.

Affected: npm: dompurify

## Impact

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](https://github.com/user-attachments/files/28604913/dompurify-trusted-types-policy-survives-clearconfig-poc.js)

## 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…

python313-comfyui-frontend-package-1.52.7-1.1 on GA media

dompurify: DOMPurify: Cross-site scripting via permanent attribute allowlist pollution dompurify: DOMPurify: Client-side arbitrary code execution due to improper Trusted Types policy reset dompurify: DOMPurify: Cross-site scripting vulnerability via attacker-controlled nodeName dompurify: DOMPurify: Sanitization bypass via hook manipulation DOMPurify: DOMPurify: Cross-site scripting due to state leakage in sanitization. dompurify: DOMPurify: URI validation bypass leads to cross-site scripting dompurify: DOMPurify: Cross-Site Scripting (XSS) via prototype pollution in USE_PROFILES mode dompurify: DOMPurify: Cross-Site Scripting vulnerability allows arbitrary code execution

Affected: Ubuntu:22.04:LTS: node-dompurify, Ubuntu:24.04:LTS: node-dompurify, Ubuntu:26.04:LTS: node-dompurify

DOMPurify 3.0.0 before 3.4.9 does not reset the retained Trusted Types policy when clearConfig() is called, so a DOMPurify instance reused across trust boundaries stays bound to a previously supplied TRUSTED_TYPES_POLICY. A later caller that requests RETURN_TRUSTED_TYPE output receives a TrustedHTML object created by the old (potentially unsafe) policy rather than a clean default, which can lead to script execution at a Trusted Types sink. Passing TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy.