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
npm install dompurify@3.4.7Details
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.
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.