deps(frontend): update dependency dompurify to v3.4.9 [security]#7790
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Playwright Test Results (oss - depot-ubuntu-latest-16)Details
Playwright Test Results (oss - depot-ubuntu-latest-arm-16)Details
|
talissoncosta
approved these changes
Jun 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
3.4.7→3.4.9DOMPurify: SAFE_FOR_TEMPLATES bypass - template expressions survive sanitization inside content when using DOM output modes
GHSA-gvmj-g25r-r7wr
More information
Details
Summary
When DOMPurify is configured with both
SAFE_FOR_TEMPLATES: trueandRETURN_DOM: true(orIN_PLACE: true), an attacker can inject template expressions, such as${evil},{{evil}}, or<%evil%>, that survive the sanitization pass inside<template>element content. This bypasses the explicit purpose ofSAFE_FOR_TEMPLATES, which is to prevent template engine evaluation of user-supplied content.Description
Background
SAFE_FOR_TEMPLATESis designed to strip{{ }},${ }, and<% %>expressions from sanitized output so that downstream template engines do not evaluate user-controlled content. The feature operates through two mechanisms:_sanitizeElements,src/purify.ts:1403), scrubs individual text nodes during the main sanitization walk._scrubTemplateExpressions,src/purify.ts:1115), callsnode.normalize()to merge adjacent text nodes, then walks the merged nodes and strips any expressions that only appeared after merging.The Gap
_scrubTemplateExpressionsuses a standardNodeIteratorrooted at the output body:Per the DOM specification, a
NodeIteratordoes not descend into<template>.content. The template element's content is a separateDocumentFragmentthat lives outside the normal child-node tree. For the same reason,node.normalize()(called on line 1116) also does not normalize text nodes inside<template>.content.This means the final normalization and scrub pass, the only pass that catches expressions formed by merging split text nodes, never runs on
<template>content.How Split Text Nodes Are Created
When DOMPurify removes a disallowed element with
KEEP_CONTENT: true(the default), it moves the element's text children into the parent node. This is the standard code path atsrc/purify.ts:1361–1373:If the removed elements were adjacent siblings inside
<template>content, their extracted text nodes end up as adjacent text nodes in the template content fragment. Each individual text node is scrubbed by_sanitizeElements, but since$and{evil}do not match any expression regex on their own, neither is modified.The code comment at
src/purify.ts:1100explicitly acknowledges the threat class:The implementation guards against this on the main body, but the guard is not applied to
<template>content.Proof of Concept
Why the Split Works
The bypass relies on splitting
${...}across two adjacent custom elements so that neither fragment matches any DOMPurify regex on its own:TMPLIT_EXPR/\${[\w\W]*/gMUSTACHE_EXPR/{{[\w\W]*|^[\w\W]*}}/g$${- no{follows{{or}}{alert(document.domain)}$- absent{{, ends with single}not}}${alert(document.domain)}DOMPurify only sees each fragment in isolation. It never merges them before checking, so the expression is never detected.
PoC 1 - XSS via
alert()(baseline confirmation)PoC 2 - Session Hijacking via cookie exfiltration
PoC 3 - End-to-end: realistic application context
This shows the full path in an application that uses DOMPurify to sanitize user-submitted rich text before rendering it with a custom template engine:
Observed output:
alert("XSS: " + document.cookie)executes in the victim's browser context, leaking session tokens to the attacker.PoC 4 -
IN_PLACEmode (DOM input path)HTML File for testing
Root Cause
_scrubTemplateExpressions(src/purify.ts:1115) does not recurse into<template>.content:The fix is to extend
_scrubTemplateExpressionsto explicitly recurse into<template>.content, mirroring the approach already used by_sanitizeShadowDOM(src/purify.ts:1753):Suggested Patch Direction
Impact
Who is affected: Applications that use DOMPurify with
SAFE_FOR_TEMPLATES: truecombined withRETURN_DOM: true,RETURN_DOM_FRAGMENT: true, orIN_PLACE: true, whose downstream template engine processes<template>element content.What an attacker can achieve: Inject arbitrary template expressions (
${...},{{...}},<%...%>) into the sanitized DOM output inside<template>elements. If the consuming template engine evaluates these expressions, this leads to template injection, which in server-side contexts can escalate to Remote Code Execution and in client-side contexts to Cross-Site Scripting.Preconditions for Exploitation
SAFE_FOR_TEMPLATES: trueRETURN_DOM: trueorIN_PLACE: true<template>.contentWhat Is NOT Affected
The string output path (default) is not affected. The final regex scrub at
src/purify.ts:2067–2071operates on the serialized HTML string, where the injected expression is visible and stripped:Severity
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:PReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
DOMPurify: Trusted Types policy survives
clearConfig()and can poison laterRETURN_TRUSTED_TYPEoutputGHSA-vxr8-fq34-vvx9
More information
Details
Impact
A DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied
TRUSTED_TYPES_POLICYeven afterclearConfig()is called. A later caller that requestsRETURN_TRUSTED_TYPEreceives aTrustedHTMLobject 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: nullon 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 commit825e617753ac1169306a542d3174a77f717a0cf6.Root cause
_parseConfig()overwritestrustedTypesPolicywhencfg.TRUSTED_TYPES_POLICYis truthy, but the default/null path only initializes the internal policy whentrustedTypesPolicy === undefined. Once a custom policy has been set, later default config parsing leaves it in place.Relevant code:
src/purify.ts:786-812accepts and storescfg.TRUSTED_TYPES_POLICY.src/purify.ts:813-832does not reset an existing policy when config has no policy or hasTRUSTED_TYPES_POLICY: null.src/purify.ts:2123-2125signs the final serialized HTML with the retained policy whenRETURN_TRUSTED_TYPEis true.src/purify.ts:2133-2136clearConfig()only clearsCONFIGandSET_CONFIG; it does not resettrustedTypesPolicyoremptyHTML.Local PoC
Run from the DOMPurify checkout, or set
DOMPURIFY_REPO: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" ] }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-controlledTrustedHTML.{ TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true }also still returns attacker-controlledTrustedHTML.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_POLICYon 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_TYPEsink.Suggested fix
Make
clearConfig()reset Trusted Types state as part of restoring defaults, or have_parseConfig()explicitly cleartrustedTypesPolicyandemptyHTMLwhenTRUSTED_TYPES_POLICY: nullis supplied.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
cure53/DOMPurify (dompurify)
v3.4.9: DOMPurify 3.4.9Compare Source
IN_PLACEsanitization, thanks @mozfreddybIN_PLACEand Trusted Types related usagev3.4.8: DOMPurify 3.4.8Compare Source
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate.