| Package | Affected versions | Patched versions |
|---|---|---|
| dompurify | ≥ 3.0.0, < 3.4.9 | 3.4.9 |
| dompurify | < 3.4.9 | 3.4.9 |
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
Tested against DOMPurify 3.4.8, repository commit 825e617753ac1169306a542d3174a77f717a0cf6.
_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.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("TT_POLICY_SURVIVED_CLEARCONFIG")\">"
},
"dialogs": [
"TT_POLICY_SURVIVED_CLEARCONFIG"
]
}
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeThe 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.{ TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true } also still returns attacker-controlled TrustedHTML.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.
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.
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.