CVE-2026-83607 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, Document.createElement(tagName) stores an unvalidated element name and XMLSerializer.serializeToString() emits that name verbatim. The requireWellFormed: true path did not validate the element qualified name or synthesized xmlns:PREFIX declaration, so attacker-controlled tag names could inject attributes, elements, or processing instructions into serialized XML or HTML and could cause cross-site scripting when browser-consumed. The unchecked values violate the XML QName constraint, and default serialization and creation-time createElement() behavior remain permissive. 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 failure in input validation during document serialization and element creation. This security flaw affects versions prior to @xmldom/xmldom 0.8.14 and 0.9.11, as well as all releases of xmldom up to version 0.6.0. The core issue stems from the permissive handling of tag names passed to the Document.createElement method and subsequently processed by XMLSerializer.serializeToString. When an attacker supplies a maliciously crafted element name, the library fails to enforce strict compliance with XML Qualified Name (QName) constraints. Instead of rejecting or sanitizing invalid characters that could alter the structural integrity of the document, the library stores these unvalidated names verbatim. This lack of validation allows for the injection of arbitrary attributes, nested elements, or processing instructions directly into the serialized output stream.
The operational impact of this vulnerability is severe, particularly in environments where the resulting XML or HTML is consumed by web browsers. Because the serializer emits the attacker-controlled content without modification, it can break out of intended structural boundaries to inject executable scripts or manipulate DOM structures. This capability facilitates Cross-Site Scripting (XSS) attacks when the serialized output is rendered in a browser context. For instance, an attacker could craft a tag name that includes script tags or event handlers, which are then embedded into the document structure and executed upon rendering. The violation of XML QName constraints means that standard parsers expecting well-formed markup may behave unpredictably, potentially leading to further exploitation vectors such as server-side request forgery if the output is processed by backend services, though the primary risk highlighted is client-side script injection.
From a technical classification perspective, this vulnerability aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. The root cause lies in CWE-20, where the application fails to properly validate input data before processing it for output generation. In terms of offensive security frameworks, this behavior maps to ATT&CK technique T1189, Drive-by Client Side Injection, and potentially T1059, Command and Scripting Interpreter, if the injected content leads to script execution. The failure occurs specifically in the requireWellFormed code path, which was intended to enforce strict XML standards but lacked comprehensive validation for qualified names and synthesized namespace declarations like xmlns:PREFIX. This oversight allows malicious payloads to bypass security controls that rely on structural integrity checks.
Mitigation strategies must prioritize upgrading to patched versions of the library where available. For users of @xmldom/xmldom, immediate upgrade to version 0.8.14 or 0.9.11 is required to resolve these validation gaps. However, for projects relying on the original xmldom package up to version 0.6.0, no official fixed version exists within that specific namespace lineage. In such cases, developers should consider migrating to alternative XML parsing libraries that enforce strict input validation and output sanitization by default. If migration is not immediately feasible, implementing a custom serialization wrapper or pre-processing step to sanitize element names against allowed character sets can provide temporary relief. It is crucial to ensure that any user-supplied data used as tag names undergoes rigorous validation before being passed to createElement methods, ensuring compliance with XML standards and preventing the injection of malicious markup structures.