CVE-2026-116803 in DOMPurify
Summary
by MITRE • 10/27/2026
DOMPurify before 3.4.17 contains a cross-site scripting vulnerability that allows attackers to keep event handlers armed when an IN_PLACE hook removes a parent or sibling node. Attacker markup in detached subtrees is never walked or neutralized, so handlers like img onerror fire after sanitize() returns, causing DOM XSS.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in versions of DOMPurify prior to 3.4.17 represents a critical flaw in the library's sanitization logic regarding detached Document Object Model subtrees and event handler persistence. This issue stems from an incomplete implementation of security controls when handling IN_PLACE hooks, which are designed to modify nodes within their existing position in the tree rather than replacing them entirely. When such a hook removes or alters a parent or sibling node during the sanitization process, the library fails to properly traverse or neutralize any remaining markup contained within detached subtrees that were previously associated with those elements. This oversight creates a significant gap in the defense-in-depth strategy employed by DOMPurify, allowing malicious payloads to persist undetected and unneutralized despite the application of standard sanitization routines.
From a technical perspective, the core flaw lies in how the sanitizer manages node detachment during iterative processing. When an IN_PLACE hook triggers the removal of a parent or sibling element, any child nodes that become detached from the main document tree are not subjected to the full recursive walk-through required for neutralizing dangerous attributes and event handlers. Consequently, if an attacker injects markup containing executable JavaScript events, such as img onerror scripts, these elements remain intact within the memory structure of the page even after the sanitize function returns control to the application. The browser continues to treat these detached nodes as valid DOM entities capable of executing code under specific trigger conditions, effectively bypassing the intended security boundaries established by the sanitization library.
The operational impact of this vulnerability is severe, particularly in applications that rely heavily on client-side rendering and dynamic content injection. Attackers can exploit this flaw to execute cross-site scripting attacks without needing to inject directly into a live node at the moment of parsing. Instead, they can embed malicious payloads within structures that become detached during routine DOM manipulation or sanitization operations. Once these payloads are embedded in the page's memory space, they remain dormant until triggered by user interaction or specific browser events. This allows for persistent storage XSS scenarios where the payload survives multiple rounds of sanitization and remains active across different views or states of the application interface, potentially leading to session hijacking, credential theft, defacement, or further malware distribution depending on the context in which the vulnerable page is rendered.
This vulnerability aligns with CWE-79, known as Improper Neutralization of Input During Web Page Generation commonly referred to as Cross-site Scripting XSS. Specifically it reflects a failure in input validation and output encoding strategies where dynamic content is not adequately sanitized before being processed by the browser engine. In terms of offensive security frameworks this behavior maps closely to ATT&CK technique T1059 which covers Command Line Interface execution via script interpreters triggered through DOM manipulation events like onerror or onload attributes. The exploitation vector typically involves crafting specific HTML structures that leverage the timing gap between node detachment and final sanitization completion, requiring precise control over how elements are removed from their parent containers during the cleaning process.
Mitigation strategies must prioritize upgrading to version 3.4.17 or later of DOMPurify where this logic has been corrected to ensure all detached subtrees undergo complete traversal and neutralization regardless of whether they were part of a modified IN_PLACE operation. Developers should also implement additional layers of defense such as Content Security Policy headers that restrict the execution of inline scripts and limit sources from which external resources can be loaded. Regular security audits focusing on how third-party libraries handle dynamic DOM changes are essential to identify similar gaps in sanitization logic. Furthermore adopting strict input validation practices at the application layer before data reaches the sanitizer adds another barrier against exploitation attempts ensuring that even if a library flaw exists it cannot easily be leveraged without first bypassing higher-level controls designed to filter malicious inputs based on known attack patterns and structural anomalies.