DOMPurify versions before 3.4.9 do not reset the retained Trusted Types policy when clearConfig() is called; a reused DOMPurify instance across trust boundaries remains bound to a previously supplied TRUSTED_TYPES_POLICY. Based on the description, it is inferred that an attacker who can supply a custom Trusted Types policy before clearConfig() is invoked—while the same DOMPurify instance remains active—can later request RETURN_TRUSTED_TYPE and receive a TrustedHTML object crafted with the older, potentially unsafe policy. When a later caller requests RETURN_TRUSTED_TYPE output, the library returns a TrustedHTML object that is created by the older, potentially unsafe policy instead of a clean default, which can lead to script execution at a Trusted Types sink. This flaw can therefore allow an attacker to inject executable HTML content that bypasses XSS defenses provided by Trusted Types.

The vulnerability affects the DOMPurify client‑side library distributed by cure53. All releases from 3.0.0 up to (but excluding) 3.4.9 are impacted. Applications that instantiate a DOMPurify object and reuse the same instance across different trust contexts are susceptible.

Based on the description, it is inferred that the attacker must be able to influence or supply a Trusted Types policy to a reused DOMPurify instance, then later trigger a Trusted Types sink after clearConfig() does not reset the policy. The likely attack vector is the manipulation of the Trusted Types policy provided to a DOMPurify instance that is reused across trust boundaries. The CVSS score of 5.1 indicates medium severity while the EPSS score of < 1% suggests a low likelihood of exploitation in the near term. The issue is not listed in the CISA Known Exploited Vulnerabilities catalog, so no active exploits have been reported. In environments that heavily rely on Trusted Types for XSS mitigation, the potential impact is higher, but the absence of documented exploits and the low EPSS value reduce the overall risk assessment for most organizations.