CVE-2026-83608: xmldom: DocType `name` Injection Bypasses requireWellFormed

Published Sep 1, 2026
·
Updated

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, the DOCUMENTTYPENODE branch in lib/dom.js validates publicId, systemId, and internalSubset under requireWellFormed: true but emits DocumentType.name verbatim. A name containing > or whitespace can terminate the <!DOCTYPE ...> declaration and inject sibling markup; the value can be supplied through createDocumentType() on the 0.8.x and unscoped lines or through a direct DocumentType.name property write on every affected line. The default path and legacy creation-time behavior remain permissive, while the vulnerable strict path fails to enforce an XML Name. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.

Affected Software

2 affected components
npm/@xmldom/xmldom<=0.8.15, >0.6.0<=0.8.14, >0.9.0<=0.9.11
npm/xmldom

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade @xmldom/xmldom to a version that resolves this vulnerability.

    Fixed in 0.8.15
  2. Upgrade

    Upgrade @xmldom/xmldom to a version that resolves this vulnerability.

    Fixed in 0.9.12

Event History

Sep 1, 2026
CVE Published
via MITRE·02:27 PM
Data Sourced
via MITRE·02:27 PM
DescriptionWeakness

Frequently Asked Questions

1

Which releases contain a fix?

The issue is fixed in @xmldom/xmldom 0.8.15 and 0.9.12. No fixed version is available for the unscoped xmldom package.

2

Does enabling requireWellFormed prevent this injection?

No. In affected versions, requireWellFormed validates the public ID, system ID, and internal subset, but does not enforce that DocumentType.name is a valid XML Name before emitting it.

3

What level of control is needed to exploit the issue?

An attacker needs control of a DocumentType name that is later serialized. On affected 0.8.x and unscoped lines this can be supplied through createDocumentType(), while every affected line permits it through a direct write to DocumentType.name.

4

Is the default behavior affected?

Yes. The default serialization path remains permissive, and legacy creation-time behavior is also permissive.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203