xmldom CVE-2026-83608

Exploitation requires that attacker-controlled data reaches the DocumentType.name field - via createDocumentType() (accessible on the 0.8.x and unscoped xmldom lines) or via direct DocumentType.name property assignment (on every affected version) - and that the document is subsequently serialized. On the @xmldom/xmldom scoped package, the documented vulnerable code path is XMLSerializer.serializeToString() with requireWellFormed: true, where validation of name is absent while sibling fields are checked; the default serialization path also emits DocumentType.name verbatim since no validation exists there either, making both paths susceptible when untrusted input is present. On the legacy unscoped xmldom package, all serialization paths are affected and no fix is available. Applications that hardcode or derive the DOCTYPE name from internal data are not at risk. Authentication requirements are not constrainable at the library level - they depend entirely on the calling application's access controls over the XML processing endpoint.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VI:H) reflects a worst-case scenario where attacker-controlled data flows directly into DocumentType.name without sanitization - plausible in XML processing pipelines or API endpoints that accept and re-serialize external documents. Real-world exploitability is gated entirely on whether the calling application passes untrusted values as the DOCTYPE name; applications that derive the name from internal, controlled data face negligible risk. No EPSS score is present in the input, so exploitation probability cannot be quantified numerically. The absence of a CISA KEV entry and lack of identified public proof-of-concept code suggest no widespread opportunistic exploitation at time of analysis, though the advisory and fix commits are now fully public, reducing the barrier to exploit development. The legacy unscoped xmldom package represents a permanent residual exposure for teams that cannot migrate to the maintained scoped package. Given the straightforward root cause - a single missing validation call - post-disclosure exploit development should be assumed in the near term, making patching or migration the appropriate response for any team using xmldom in an externally-facing XML processing role.

An attacker submits an API request or document where a DOCTYPE name field contains a crafted value such as 'legit><injected-element/><!--', which the application passes without sanitization to createDocumentType() or assigns to DocumentType.name. When XMLSerializer.serializeToString() is called, the '>' terminates the DOCTYPE declaration early and the injected markup appears as a sibling node in the serialized output. If that output is forwarded to a downstream XML parser, XSLT processor, or rendered in a browser context trusting the serializer's output, the injected nodes may be interpreted, enabling content injection or trust boundary violations between systems.