CVE-2026-83609 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. From 0.9.0 until 0.9.12, the shared reg() builder in lib/grammar.js compiles the anchored QName_exact validator with the multiline flag, so ^ and $ validate only one line instead of the complete name. createElementNS, createAttributeNS, createDocumentType, and createAttribute consequently accept a malformed XML name whose first line is valid and whose later text injects markup when serialized through either the default path or requireWellFormed: true. The triggering ECMAScript line terminators are U+000A, U+000D, U+2028, and U+2029. This issue is fixed in @xmldom/xmldom version 0.9.12.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified within the xmldom library stems from a flaw in its regular expression handling for XML name validation during specific DOM manipulation operations. The core of the issue resides in the shared reg builder located in lib/grammar.js, which compiles the anchored QName_exact validator with the multiline flag enabled. In standard JavaScript regular expressions, when the multiline flag is active, the caret symbol anchors to the start of any line within a string rather than just the beginning of the entire input, and similarly for end-of-line assertions. This configuration causes the validation logic to accept XML names that are technically malformed because it only validates the first line of the name against strict XML naming conventions while ignoring subsequent lines.
This technical flaw allows an attacker or malicious script to inject markup through specially crafted inputs passed to methods such as createElementNS, createAttributeNS, createDocumentType, and createAttribute. These functions rely on the QName_exact validator to ensure that node names conform to W3C standards for XML naming rules. Due to the multiline flag misconfiguration, if an input string contains valid characters in its first line followed by a line terminator character such as U+000A (line feed), U+000D (carriage return), U+2028 (line separator), or U+2029 (paragraph separator), the validator considers the name acceptable. When this malformed node is subsequently serialized, either through the default serialization path or when requireWellFormed is set to true, the injected markup from subsequent lines can be rendered as actual XML tags or attributes rather than being escaped or rejected.
The operational impact of this vulnerability is significant for applications that process untrusted XML data and rely on xmldom for parsing and manipulation before rendering or further processing. An attacker could exploit this flaw to perform XML injection attacks, potentially leading to cross-site scripting if the output is rendered in a browser context without proper sanitization. It also undermines the integrity of XML documents by allowing structurally invalid nodes that can disrupt downstream parsers or applications expecting well-formed XML input. The issue affects versions from 0.9.0 up through and including 0.9.12, representing a period where this specific regex configuration was active in the library's grammar processing logic.
From a classification perspective, this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements used in an XML Document, as it allows for the injection of unintended markup elements due to insufficient validation of input data boundaries. It also relates to CWE-20 Improper Input Validation because the application fails to correctly validate user-supplied input against expected patterns before processing. In terms of attack vectors, this could be leveraged within ATT&CK techniques related to Injection or potentially as part of a broader exploitation chain involving XML External Entity attacks if combined with other vulnerabilities in the consuming application's configuration.
To mitigate this risk, organizations using affected versions must upgrade immediately to @xmldom/xmldom version 0.9.12 or later where the issue has been resolved by correcting the regular expression flags and validation logic. For systems that cannot be upgraded instantly, implementing strict input sanitization at the application layer is recommended. This includes validating XML node names against a whitelist of allowed characters before passing them to xmldom methods. Additionally, ensuring that any serialized output undergoes proper encoding or escaping based on its context can help prevent the execution of injected markup if it manages to bypass initial validation checks.