CVE-2026-83608

xmldom and @xmldom/xmldom fail to validate the DocumentType name when running in strict mode (requireWellFormed: true): publicId, systemId, and internalSubset are checked, but the name is emitted verbatim into the <!DOCTYPE ...> declaration. An attacker who controls a doctype name — via createDocumentType() on the 0.8.x and unscoped 0.6.0-and-earlier lines, or via a direct write to DocumentType.name on every affected line — can use a '>' or whitespace character to terminate the declaration early and inject sibling markup into the serialized XML. This corrupts or tampers with XML delivered to downstream consumers, scored as a network-exploitable, high-integrity issue (CVSS 4.0 8.7) with no confidentiality or availability impact. Any npm-consuming application that serializes XML with @xmldom/xmldom prior to 0.8.15 or 0.9.12, or with the legacy unscoped xmldom package 0.6.0 and earlier, is affected; deployments using only the default permissive path are less likely to be exploitable. No exploitation has been reported: there is no public proof-of-concept, the flaw is not in CISA's KEV, and EPSS estimates a 0.3% chance of exploitation within 30 days.

What to do: Upgrade to @xmldom/xmldom 0.8.15 or 0.9.12 (or later); the legacy unscoped xmldom package has no fixed release, so migrate to the scoped @xmldom/xmldom package. Audit code that calls createDocumentType() or writes DocumentType.name with user-controlled input and, as a mitigation, validate that the name matches an XML Name production (no '>' or whitespace) before serialization, especially when running with requireWellFormed: true. Scan your dependency tree (npm audit/lockfiles) for both xmldom and @xmldom/xmldom to find affected transitive dependencies.