Description
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 products
cure53: dompurify
References3
- github.com/cure53/DOMPurify/commit/825e617753ac1169306a542d3174… Patch
- github.com/cure53/DOMPurify/security/advisories/GHSA-vxr8-fq34-… ExploitThird Party Advisory
- www.vulncheck.com/advisories/dompurify-before-trusted-types-pol… Third Party Advisory
Metrics
- CVSS 3.1
-
6.1
MEDIUM
Score source: CNA
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N - CVSS 4.0
-
5.1
MEDIUM
Score source: CNA
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - EPSS — exploit probability
- 0% percentile: 36 · as of 14 November 2026
- CWE
- CWE-693
Could this be exploited in your environment?
A patch closes the known hole. A penetration test shows what an attacker can still reach — with proof.