GHSA-VXR8-FQ34-VVX9

Vulnerability from github – Published: 2026-06-15 20:12 – Updated: 2026-07-23 13:59
VLAI
Summary
DOMPurify: Trusted Types policy survives `clearConfig()` and can poison later `RETURN_TRUSTED_TYPE` output
Details

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

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.

Suggested fix

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.

Severity
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "dompurify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-65899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:12:53Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Impact\n\nA 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.\n\nIf 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.\n[dompurify-trusted-types-policy-survives-clearconfig-poc.js](https://github.com/user-attachments/files/28604913/dompurify-trusted-types-policy-survives-clearconfig-poc.js)\n\n\n## Affected version\n\nTested against DOMPurify `3.4.8`, repository commit `825e617753ac1169306a542d3174a77f717a0cf6`.\n\n## Root cause\n\n`_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.\n\nRelevant code:\n\n- `src/purify.ts:786-812` accepts and stores `cfg.TRUSTED_TYPES_POLICY`.\n- `src/purify.ts:813-832` does not reset an existing policy when config has no policy or has `TRUSTED_TYPES_POLICY: null`.\n- `src/purify.ts:2123-2125` signs the final serialized HTML with the retained policy when `RETURN_TRUSTED_TYPE` is true.\n- `src/purify.ts:2133-2136` `clearConfig()` only clears `CONFIG` and `SET_CONFIG`; it does not reset `trustedTypesPolicy` or `emptyHTML`.\n\n## Local PoC\n\nRun from the DOMPurify checkout, or set `DOMPURIFY_REPO`:\n\n```bash\nnode /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js\n```\n\nObserved output:\n\n```json\n{\n  \"result\": {\n    \"baseline\": \"\u003cb\u003ebaseline\u003c/b\u003e\",\n    \"duringPolicy\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"afterClearString\": \"\u003cimg src=\\\"x\\\"\u003e\",\n    \"afterClearTrustedType\": \"[object TrustedHTML]\",\n    \"afterClearTrusted\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"afterNullTrusted\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"mountedHTML\": \"\u003cimg src=\\\"x\\\" onerror=\\\"alert(\u0026quot;TT_POLICY_SURVIVED_CLEARCONFIG\u0026quot;)\\\"\u003e\"\n  },\n  \"dialogs\": [\n    \"TT_POLICY_SURVIVED_CLEARCONFIG\"\n  ]\n}\n```\n\nThe important part is the split behavior after cleanup:\n\n- `purify.clearConfig(); purify.sanitize(...);` returns a normal sanitized string (`\u003cimg src=\"x\"\u003e`), because the later call is not asking for a Trusted Type.\n- `purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true });` still uses the old policy and returns attacker-controlled `TrustedHTML`.\n- Passing `{ TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true }` also still returns attacker-controlled `TrustedHTML`.\n\n## Preconditions\n\nThis 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.\n\nThis 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.\n\n## Severity\n\n 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.\n\n## Suggested fix\n\nMake `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.",
  "id": "GHSA-vxr8-fq34-vvx9",
  "modified": "2026-07-23T13:59:23Z",
  "published": "2026-06-15T20:12:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-vxr8-fq34-vvx9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cure53/DOMPurify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DOMPurify: Trusted Types policy survives `clearConfig()` and can poison later `RETURN_TRUSTED_TYPE` output"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.