Skip to content

🚨 [security] Update dompurify 3.4.8 → 3.4.10 (patch)#175

Open
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/npm/dompurify-3.4.10
Open

🚨 [security] Update dompurify 3.4.8 → 3.4.10 (patch)#175
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/npm/dompurify-3.4.10

Conversation

@depfu

@depfu depfu Bot commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!


Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ dompurify (3.4.8 → 3.4.10) · Repo

Security Advisories 🚨

🚨 DOMPurify: Trusted Types policy survives `clearConfig()` and can poison later `RETURN_TRUSTED_TYPE` output

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.

Release Notes

3.4.10

  • Refactored codebase for clarity: extracted the public type declarations into types.ts
  • Decomposed the three largest sanitizer functions into focused helpers
  • Removed duplicated defaults and dead branches, consolidated SAFE_FOR_TEMPLATES scrubbing into single shared path
  • Improved per-node performance by hoisting the mXSS probe regexes and testing textContent before innerHTML
  • Added a deterministic micro-benchmark harness (npm run bench) with a --compare mode
  • Reduced CI cost by running the full three-engine browser suite once per PR
  • Refreshed the demos/ folder so every demo runs again, and added a SVG-via-<img> demo
  • Documented the bench and test:happydom scripts in the README
  • Completed the Attack Classes & Bypass History wiki page
  • Bumped several dependencies where possible

3.4.9

  • Further improved the handling of Trusted Types config options, thanks @offset
  • Further improved the handling of IN_PLACE sanitization, thanks @mozfreddyb
  • Added more test coverage for IN_PLACE and Trusted Types related usage
  • Bumped several dependencies where possible
  • Updated README and wiki with more accurate documentation & attack samples

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 2 commits:


Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)
Go to the Depfu Dashboard to see the state of your dependencies and to customize how Depfu works.

@depfu depfu Bot added the depfu label Jun 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants