CVE-2026-83610 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.15 and 0.9.12, and in xmldom version 0.6.0 and earlier, Document.createEntityReference(name) accepts an invalid name and the ENTITY_REFERENCE_NODE serializer emits the resulting nodeName directly in &name; form. Directly serializing the node or fragment with XMLSerializer.serializeToString() and requireWellFormed: true can therefore break the entity-reference boundary and produce attacker-controlled XML markup when reparsed. The parser does not ordinarily create these nodes, and element-child insertion is rejected, so exploitation requires an application to create and directly serialize an EntityReference. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
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 significant risk to applications that rely on dynamic XML generation and serialization. The core issue lies within the Document.createEntityReference method, which fails to adequately validate the name parameter provided during entity reference creation. In versions prior to @xmldom/xmldom 0.8.15 and 0.9.12, as well as in xmldom version 0.6.0 and earlier, this function accepts invalid or malformed names without raising an error. This lack of input validation allows attackers to inject arbitrary strings that are not compliant with XML entity naming conventions directly into the DOM structure via programmatic creation rather than parsing untrusted external data.
The technical flaw manifests during the serialization phase when using the XMLSerializer.serializeToString method, particularly when the requireWellFormed option is enabled or implied by strict validation settings in downstream consumers. When an EntityReference node with an invalid name is serialized, the library emits it directly as &name;, where name represents the attacker-controlled string. Because standard XML parsers expect entity references to follow specific syntactic rules, this output can break the expected boundary of well-formedness. If this serialized output is subsequently reparsed by another system or application that does not strictly enforce pre-serialization validation, the malformed entity reference may be interpreted as a new structural element or trigger unexpected parsing behaviors. This discrepancy between creation and serialization creates a vector for XML Injection attacks, where an attacker can manipulate the structure of the resulting XML document.
From an operational impact perspective, this vulnerability enables scenarios akin to Cross-Site Scripting (XSS) if the serialized XML is rendered in a browser context that interprets entities or converts them back to HTML-like structures. It also poses risks for server-side applications that process these documents further down the pipeline, potentially leading to data injection, denial of service through malformed document processing, or bypassing security filters that rely on predictable entity formatting. The attack vector is specific because the parser itself does not create such nodes from external input; exploitation requires an application developer to explicitly call Document.createEntityReference with untrusted user-supplied data and then serialize it without adequate sanitization checks in between. This makes the vulnerability dependent on improper usage patterns within the host application rather than a direct remote code execution flaw in the library's parsing engine.
To mitigate this risk, developers must ensure they are using patched versions of the library where available. Specifically, upgrading to xmldom/xmldom version 0.8.15 or higher is critical for projects utilizing that package namespace. For applications still dependent on the original xmldom package (version 0.6.0 and earlier), no fixed version exists within that specific npm scope, necessitating a migration to an actively maintained alternative such as xmldom/xmldom or another robust XML processing library like fast-xml-parser or xml2js, which implement stricter validation standards. Additionally, application-level mitigations should include implementing strict input validation on any data passed to createEntityReference calls and ensuring that serialization processes validate the well-formedness of the output before transmission or storage. This aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component (Injection) and maps to ATT&CK techniques related to Injection, specifically T1059 Command Scripting if the XML is executed in an environment that interprets entities as commands, though primarily it falls under general injection vulnerabilities affecting data integrity.