CVE-2026-83618 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.10 until 0.9.12, the requireWellFormed: true serializer validates DocumentType.publicId and DocumentType.systemId with PubidLiteral_match and SystemLiteral_match expressions produced by reg() in lib/grammar.js, which inherit the multiline flag. A complete valid literal on the first line can therefore satisfy the matcher while U+000A, U+000D, U+2028, or U+2029 and breakout markup remain in the emitted <!DOCTYPE ...> declaration. This bypasses the strict-serialization mitigation for the earlier DocumentType injection advisory; creation and direct property assignment remain unvalidated by design. This issue is fixed in @xmldom/xmldom version 0.9.12.
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 xmldom versions from 0.9.10 through 0.9.12 represents a critical flaw in the serialization logic for XML DocumentType declarations, specifically affecting the handling of public and system identifiers when strict well-formedness validation is enabled. The core issue stems from regular expression patterns used to validate PubidLiteral and SystemLiteral values within the library's grammar definition file. These regex expressions were configured with the multiline flag active during their construction via a helper function in lib/grammar.js. While this configuration was intended to ensure that input strings strictly adhere to XML standards by checking for valid characters, it inadvertently introduced a bypass mechanism due to how line terminators are processed within multiline matching contexts.
When an attacker provides a DocumentType declaration where the publicId or systemId contains specific Unicode newline characters such as U+000A (LF), U+000D (CR), U+2028 (LINE SEPARATOR), or U+2029 (PARAGRAPH SEPARATOR) embedded within the value, the multiline regex matcher can be tricked into considering the input valid. Specifically, if a complete and syntactically correct literal appears on the first line of the identifier string, the regular expression considers the validation successful for that segment. However, this leaves subsequent characters, including dangerous newline sequences and potential breakout markup, unvalidated in the final serialized output. This behavior allows malicious content to be injected into the <!DOCTYPE> declaration despite the serializer being configured with requireWellFormed set to true, effectively neutralizing a security mitigation designed to prevent such injections.
This flaw directly undermines previous security advisories regarding DocumentType injection by exploiting the gap between validation and serialization. The vulnerability arises because while input parsing might reject malformed structures during initial DOM construction, the subsequent step of serializing that structure back into an XML string fails to re-validate or sanitize properties like publicId and systemId with sufficient rigor when multiline flags are involved. Consequently, attackers can craft payloads where the visible portion of the identifier appears valid, but hidden control characters allow for line breaks in the outputted DOCTYPE declaration. This can lead to unexpected parsing behaviors in downstream XML processors that consume this serialized data, potentially leading to information disclosure or further injection attacks depending on how the resulting XML is processed by client-side scripts or server-side parsers.
From a classification perspective, this vulnerability aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS), particularly in contexts where serialized data influences subsequent parsing stages. It also relates to CWE-20, indicating improper input validation, specifically the failure to validate all components of a structured input string against expected constraints before outputting it. In terms of offensive security frameworks such as MITRE ATT&CK, this technique supports techniques associated with Injection and potentially Command or Script Interpretation if the serialized XML is processed by vulnerable downstream applications that interpret DOCTYPE declarations for external entity resolution or other extended features.
The operational impact of this vulnerability depends heavily on the application's usage of xmldom. If the library is used to generate XML responses sent to browsers, an attacker could potentially inject scripts or malicious markup via the DOCTYPE declaration if the browser's parser interprets the injected content in a way that executes code or alters document structure unexpectedly. Even without direct script execution, the ability to break out of expected structural boundaries can disrupt parsing logic, leading to denial-of-service conditions through malformed XML structures or causing data integrity issues by corrupting the intended schema definition embedded within the DOCTYPE.
To mitigate this risk, organizations relying on affected versions must upgrade immediately to @xmldom/xmldom version 0.9.12 or later, where the serialization logic has been corrected to properly handle multiline inputs and ensure that all parts of publicId and systemId are validated against strict well-formedness rules without reliance on potentially misleading regex flags. For applications unable to upgrade immediately, implementing additional input validation layers at the application level is recommended. This includes sanitizing any user-supplied data intended for DocumentType properties before passing it to the xmldom library, ensuring that no newline characters or other control codes are present in publicId and systemId fields. Furthermore, developers should review how serialized XML output is consumed by downstream systems, applying strict parsing policies such as disabling external entity resolution if applicable, to reduce the attack surface even if serialization flaws exist.