xmldom CVE-2026-83610

Exploitation requires three simultaneous application-level conditions: (1) the application explicitly calls Document.createEntityReference() with attacker-controlled input - this API is never invoked by the xmldom parser itself during XML parsing, so the vulnerable path is entirely application-driven; (2) the resulting node or a document fragment containing it is passed to XMLSerializer.serializeToString() with the requireWellFormed: true option enabled; and (3) the serialized XML string is subsequently consumed by a downstream parser in a security-relevant context where injected XML structure has meaningful effect. Applications that use xmldom only for parsing (DOMParser.parseFromString) and never construct EntityReference nodes programmatically are entirely unaffected. The CVSS 4.0 AT:P metric formally captures this specific-precondition requirement. There is no confidentiality or availability impact; only the structural integrity of serialized XML output is at risk.

The CVSS 4.0 score of 6.3 Medium with AT:P (attack precondition required) accurately reflects the constrained nature of this flaw. Real-world exposure is significantly narrower than a generic network-injection vulnerability: the attack surface is limited to applications that both construct EntityReference nodes programmatically from untrusted input and serialize them with requireWellFormed: true, a pattern that is uncommon in production code. The integrity-only impact (VI:L, no VC or VA) is consistent with XML structure injection - an attacker can manipulate output XML structure for a downstream parser but cannot directly exfiltrate data or crash the service. No EPSS score is provided in the input data, but the absence from CISA KEV and the lack of any known public exploit code suggest exploitation probability is currently low. The legacy xmldom package carries permanent risk since no patch will be released; for those deployments, migration to @xmldom/xmldom is the only durable remediation, and security teams should flag any dependency on the unmaintained package regardless of whether the specific EntityReference code path is exercised.

An attacker submits a crafted string to a web service that uses xmldom to build an XML document programmatically, where the string reaches a Document.createEntityReference() call as the entity name. The service then serializes the document with XMLSerializer.serializeToString() and requireWellFormed: true and forwards the result to a downstream XML processor - for example, an SAML assertion consumer, an XML-based API gateway, or a configuration pipeline. The unescaped &attacker-payload; in the output allows the attacker to inject element boundaries, close attribute values, or embed processing instructions visible to the downstream parser. No public proof-of-concept is known at time of analysis.