CVE-2026-83605 in xmldom
Summary
by MITRE • 09/01/2026
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.14 and 0.9.11, and in xmldom version 0.6.0 and earlier, Element.setAttribute() calls the private _createAttribute(name) path without validating the attribute name, while Document.createAttribute(name) validates against QName. XMLSerializer.serializeToString() emits attribute names verbatim, and requireWellFormed: true did not validate them, so a crafted name can terminate the intended attribute and inject additional attributes, including event handlers, into browser-consumed output; synthesized xmlns:PREFIX declarations expose the same unchecked-name boundary. This issue is fixed in @xmldom/xmldom versions 0.8.14 and 0.9.11; no fixed version is available for xmldom.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the xmldom library, a pure JavaScript implementation of the W3C XML DOM Level 2 Core standard, represents a critical input validation failure within its attribute handling mechanisms. Specifically, versions prior to @xmldom/xmldom 0.8.14 and 0.9.11, as well as xmldom version 0.6.0 and earlier, exhibit inconsistent behavior when processing element attributes. The core technical flaw lies in the discrepancy between how attribute names are validated during creation versus serialization. When an application calls Element.setAttribute(), it invokes a private internal method named _createAttribute which fails to validate the structure of the provided name string against XML Name constraints. In contrast, the Document.createAttribute() method correctly enforces these validations by checking for valid QName (Qualified Name) structures. This inconsistency creates a security gap where malicious actors can bypass standard validation checks if they utilize the Element.setAttribute pathway rather than the Document-based approach.
The operational impact of this flaw is severe due to how the library handles serialization and output generation. The XMLSerializer.serializeToString() method emits attribute names verbatim without performing any additional sanitization or structural verification, even when the requireWellFormed option is set to true. This design oversight allows an attacker to inject crafted strings that contain characters such as spaces, equals signs, or quotes within the attribute name itself. Because these characters are not stripped or escaped during serialization, they can effectively terminate the intended attribute value and introduce new attributes into the resulting XML document. In contexts where this serialized output is consumed by a browser-based environment, such as when generating HTML fragments or processing data for client-side rendering, this capability enables Cross-Site Scripting attacks. An attacker could inject event handler attributes like onload or onerror, leading to arbitrary code execution within the victim's browser session.
Furthermore, the vulnerability extends beyond simple attribute injection into namespace declaration handling. The library synthesizes xmlns:PREFIX declarations based on unchecked names, exposing the same boundary validation failure. If an attacker can control a prefix used in these synthesized namespaces, they may manipulate XML parsing contexts or introduce malicious namespace definitions that could be exploited for further attacks, such as XML External Entity injections if other processing steps are involved. This issue is classified under CWE-20: Improper Input Validation and aligns with MITRE ATT&CK techniques related to Client-Side Scripting Injection, specifically T1059.007 (JavaScript) when the output is rendered in a browser context. The lack of validation on attribute names violates fundamental principles of secure coding for XML processors, which must strictly enforce lexical constraints defined by the W3C specification before emitting data.
Mitigation strategies require immediate updates to patched versions where available. For users employing @xmldom/xmldom, upgrading to version 0.8.14 or 0.9.11 resolves the issue as these releases implement consistent validation across all attribute creation pathways. However, for projects relying on the original xmldom package (version 0.6.0 and earlier), no fixed version is currently available from the maintainers. In such cases, organizations must consider migrating to alternative maintained XML processing libraries that adhere strictly to W3C standards and implement robust input validation. Additionally, if migration is not immediately feasible, developers should apply defensive coding practices by manually validating all attribute names against valid QName patterns before passing them to setAttribute methods. This includes ensuring that attribute names do not contain spaces, special characters like equals signs or quotes, and conforming to the lexical rules of XML Namespaces. Implementing strict output encoding for any dynamic content rendered in browser contexts also provides a secondary layer of defense against potential script injection vectors arising from this vulnerability.