MediumGHSA-rp9w-3fw7-7cwqCVE-2026-49978

DOMPurify IN_PLACE Sanitization Bypass via Attached Shadow Root Inside <template>.content

Published 15 Jun 2026 · Updated 10 Sept 2026

Affected package

Affected
<3.4.7
Fixed in
3.4.7
Update to the fixed version for your release line, for example:npm install dompurify@3.4.7

Details

If the HTML you give it contains a <template> element, and inside that template there's an element with a shadow DOM attached to it, DOMPurify quietly skips over the shadow contents. Whatever the attacker put in there - an image with an onerror handler, a link with a javascript: URL, even a full script - survives untouched. The moment the application uses that template the way templates are meant to be used (cloning it and inserting the result into the page), the malicious payload comes along and runs as if it had never been sanitized. From there an attacker gets everything XSS normally gets them: session cookies, stored tokens, the ability to act as the user, and the ability to leave persistent payloads behind for the next person who visits.

advisory.pdf

poc.html

Is GHSA-rp9w-3fw7-7cwq in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected dompurify, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.