Ce mail provient de l'extérieur, restons vigilants

=====================================================================


                            CERT-Renater

                Note d'Information No. 2026/VULN1072
_____________________________________________________________________

DATE                : 23/10/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running dompurify (npm) versions prior
                                      to 3.4.17.

====================================================================
https://github.com/advisories/GHSA-cg2g-xh64-v4q7
_____________________________________________________________________

DOMPurify SAFE_FOR_TEMPLATES bypass: split template expressions
survive in attached shadow root content on DOM output modes

Critical severity GitHub Reviewed Published 2 weeks ago in
cure53/DOMPurify • Updated yesterday


Vulnerability details

Package
dompurify (npm)

Affected versions
>= 3.4.4, <= 3.4.16

Patched versions
3.4.17


Description

Summary

When DOMPurify is configured with SAFE_FOR_TEMPLATES: true together
with a DOM-returning mode (RETURN_DOM: true, RETURN_DOM_FRAGMENT: true,
or IN_PLACE: true), template expressions such as {{...}}, ${...},
and <%...%> survive sanitization inside the text content of an attached
shadow root. The post-walk safety net _scrubTemplateExpressions
(src/purify.ts:1717) was extended to recurse into <template>.content,
but it never recurses into attached shadow roots. An attacker who can
supply a DOM node carrying a shadow root (the IN_PLACE and shadow-aware
RETURN_DOM surfaces) can split an expression across text nodes separated
by disallowed elements; after those elements are removed the fragments
become adjacent and serialize into a complete expression that a
downstream template engine will evaluate.


Root Cause

SAFE_FOR_TEMPLATES neutralizes template expressions through two mechanisms:
a per-text-node strip during the main walk (_stripTemplateExpressions,
applied in _sanitizeElements at src/purify.ts:2246), and a final
post-walk pass (_scrubTemplateExpressions, src/purify.ts:1717) that
normalizes adjacent text nodes and re-strips expressions that only form
after merging. The per-node strip cannot catch an expression that is
split into individual fragments, because each fragment fails the
delimiter regexes. The post-walk pass is the only mechanism that
would catch the merged form, but it is structurally unable to reach
shadow root content.

_scrubTemplateExpressions (src/purify.ts:1717-1751):
  - node.normalize() at line 1718 does not merge text nodes inside 
shadow roots (DOM spec).
  - NodeIterator at lines 1723-1731 does not descend into shadow
trees (DOM spec).
  - Explicit recursion at lines 1743-1750 enters <template>.content
    only, via querySelectorAll('template'); there is no equivalent
    recursion into attached shadow roots.
Shadow roots are sanitized earlier by _sanitizeShadowDOM (src/purify.ts:2710),
which applies the per-node strip but never performs the post-walk
normalize-and-rescrub.

Shadow root text nodes are therefore sanitized only per-node and
never re-examined as a merged unit.


Impact

An attacker who controls DOM-node input containing an attached
shadow root can inject template expressions that survive sanitization
and are later evaluated by the application's template engine. In
client-side contexts this yields cross-site scripting; in a
server-side template context it can escalate to template
injection. Exploitation requires non-default application
configuration: the application must enable SAFE_FOR_TEMPLATES
and a DOM-returning mode, pass a DOM node that already has an
attached shadow root, and feed the sanitized shadow root content
into a template evaluator. The shadow root does not have to be
built programmatically with attachShadow: in engines that support
declarative shadow DOM, attacker-supplied markup containing
<template shadowrootmode="open"> parsed through setHTMLUnsafe
or Document.parseHTMLUnsafe produces the same attached shadow
root, so a plain HTML string reaches the gap once the application
is configured this way. Demonstrated capability is injection of
a complete, attacker-chosen expression into post-sanitization
shadow root content; the resulting script execution and any
confidentiality or integrity consequence depend on the
downstream engine's evaluation context.


Proof of Concept

Preconditions:
  - DOMPurify built from the affected source (dist/purify.js
or an ESM/CJS bundle).
  - A browser (or DOM implementation) with shadow DOM support.
  - Application constructs a DOM node with an attached shadow
root before sanitizing,
    and later evaluates the shadow root's text content as a
template.

Build a host element whose shadow root holds a template expression
split across text nodes separated by disallowed elements,
then sanitize in place with SAFE_FOR_TEMPLATES:

const host = document.createElement('div');
const root = host.attachShadow({ mode: 'open' });

// Split "${alert(document.domain)}" so no single fragment matches a regex.
// <object> is not in the default ALLOWED_TAGS and is removed during sanitization,
// leaving the surrounding text-node siblings adjacent.
root.appendChild(document.createTextNode('$'));
root.appendChild(document.createElement('object'));
root.appendChild(document.createTextNode('{alert(document.domain)}'));

DOMPurify.sanitize(host, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true });

// After the disallowed element is removed, the fragments are adjacent and survive.
host.shadowRoot.normalize();
console.log(host.shadowRoot.textContent);

${alert(document.domain)}

A downstream template evaluator reading shadowRoot.textContent
(for example new Function('return ' + content + '')() or any ${...}/{{...}} engine)
then evaluates the fully formed expression.


Attack Chain

    Exposure: The application call
     DOMPurify.sanitize(node, cfg) (src/purify.ts:2854) with
      SAFE_FOR_TEMPLATES: true and IN_PLACE: true (or a
      shadow-aware RETURN_DOM), passing a DOM node that
      already carries an attached shadow root.
    Control: The attacker controls the shadow root's text
      nodes and the disallowed separator elements between them;
      each fragment ($, {alert(document.domain)}) is a valid,
      individually benign text node.
    Path: _sanitizeAttachedShadowRoots (src/purify.ts:2977) feeds
the shadow root into _sanitizeShadowDOM (src/purify.ts:2710), which
strips expressions per text node (src/purify.ts:2246) and removes
the disallowed separator elements, leaving the fragments adjacent.
    Guard: The post-walk safety net _scrubTemplateExpressions (src/purify.ts:3131-3132)
         is the only pass that would catch the merged
         expression, but it never recurses into shadow roots
        (src/purify.ts:1717-1751 recurses into <template>.content only).
    Primitive: The adjacent fragments serialize as a single
         concatenated string on shadowRoot.textContent / shadowRoot.innerHTML,
         reconstituting the complete expression.
    Result: A downstream template engine evaluates the
         attacker-chosen expression, achieving script execution
        (or template injection) in the engine's context.

Bypass Evidence

The relevant protection is SAFE_FOR_TEMPLATES, specifically the
post-walk pass that defends against expressions that only form after
adjacent text nodes merge. That defense was previously extended to
<template>.content under CVE-2026-65900 (GHSA-gvmj-g25r-r7wr) by
adding querySelectorAll('template') recursion at
src/purify.ts:1743-1750. The strongest challenge is whether any code
path performs the equivalent merge-and-rescrub inside shadow roots.
Enumerating every call site of _scrubTemplateExpressions
(src/purify.ts:1717, 1747, 3132, 3141) shows none receive a shadow root,
and _sanitizeShadowDOM (src/purify.ts:2710) never
calls _scrubTemplateExpressions or normalize(). The per-node strip
cannot compensate: MUSTACHE_EXPR (src/regexp.ts:3) requires
{{ or }}, TMPLIT_EXPR (src/regexp.ts:5) requires ${, and
ERB_EXPR (src/regexp.ts:4) requires <% or %>, none of which appear in
a single-character fragment. The CVE-2026-65900 regression tests exercise
<template>.content only; no test covers shadow root content under
SAFE_FOR_TEMPLATES. The gap is therefore an unfixed case on a distinct
remediation boundary (shadow roots) rather than a bypass of the delivered
template-content fix.


Affected Versions

    Ecosystem: npm
    Package: dompurify
    Confirmed affected range: >= 3.4.4, <= 3.4.16
    Latest release checked: 3.4.16 (npm registry)
    Fix status: not fixed

The lower bound 3.4.4 is the release that introduced both the
attached-shadow-root sanitization pass and the _scrubTemplateExpressions
safety net; releases 3.4.4 through 3.4.7 carry the safety net with no
content-container recursion, and 3.4.8 onward add <template>.content
recursion but still omit shadow root recursion. No published release
and no current development revision contains a shadow-root fix.


Suggested Fix

Enforce the same post-walk normalize-and-rescrub invariant on attached
shadow roots that already applies to <template>.content.
After _sanitizeShadowDOM finishes walking a shadow root,
run _scrubTemplateExpressions over that shadow root so adjacent tex
 nodes created by element removal are merged and re-stripped;
alternatively, have _scrubTemplateExpressions discover and recurse into
attached shadow roots as it does for template content. The fix must
cover nested shadow roots and shadow roots inside <template>.content,
and it must handle all three expression dialects, since any disallowed
element can serve as the separator that produces adjacent fragments.

Reported by zx (GitHub: @manus-pi).
References

    GHSA-cg2g-xh64-v4q7
    cure53/DOMPurify#1672
    cure53/DOMPurify@a77a3e7
    https://github.com/cure53/DOMPurify/releases/tag/3.4.17


Severity
Critical
9.2/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity High
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability Low
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

EPSS score

Weaknesses
Weakness CWE-79

CVE ID
No known CVE

GHSA ID
GHSA-cg2g-xh64-v4q7

Source code
cure53/DOMPurify

Credits

    @manus-pi manus-pi Reporter
    @manus-use manus-use Reporter


=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================