Vulnerabilities

Security research · GHSA-cg2g-xh64-v4q7

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

Published Oct 22, 2026 · catalog updated Oct 22, 2026 · DOMPurify SAFE_FOR_TEMPLATES bypass: split

Last checked Oct 23, 2026, 13 days ago.

Open the advisory

Exploitation likelihood is not on this record for GHSA-cg2g-xh64-v4q7. A missing EPSS score is not a low risk. Compare DOMPurify SAFE_FOR_TEMPLATES bypass: split with the linked advisory before you change production.

Severity

Critical—

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Awaiting synchronization with FIRST

Remediation

Version ranges on file

Affected products

npm dompurify

## Summary When DOMPurify is configured with together with a DOM-returning mode ( , , or ), template expressions such as , , and survive sanitization inside the text content of an attached shadow root. The post-walk safety net ( ) was extended to recurse into , but it never recurses into attached shadow roots. An attacker who can supply a DOM node carrying a shadow root (the and shadow-aware 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 neutralizes template expressions through two mechanisms: a per-text-node strip during the main walk ( , applied in at ), and a final post-walk pass ( , ) 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. 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 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 : in engines that support declarative shadow DOM, attacker-supplied markup containing par