Hi,
The following vulnerabilities were published for node-xmldom.
CVE-2026-83608[0]:
| 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 DOCUMENT_TYPE_NODE 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.
CVE-2026-83609[1]:
| xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2
| Core) DOMParser and XMLSerializer module. From 0.9.0 until 0.9.12,
| the shared reg() builder in lib/grammar.js compiles the anchored
| QName_exact validator with the multiline flag, so ^ and $ validate
| only one line instead of the complete name. createElementNS,
| createAttributeNS, createDocumentType, and createAttribute
| consequently accept a malformed XML name whose first line is valid
| and whose later text injects markup when serialized through either
| the default path or requireWellFormed: true. The triggering
| ECMAScript line terminators are U+000A, U+000D, U+2028, and U+2029.
| This issue is fixed in @xmldom/xmldom version 0.9.12.
CVE-2026-83610[2]:
| 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.
CVE-2026-83611[3]:
| 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,
| DOMParser.parseFromString() can silently accept an end tag such as
| </a\njunk>, close the element, and discard the trailing content. On
| 0.9.x, the lib/sax.js end-tag validator inherits the multiline flag
| from reg(), allowing the first line to satisfy the anchored XML ETag
| production; older lines have no equivalent residue validation. This
| parser differential can bypass a parse-before-trust well-formedness
| gate, although it does not inject the discarded content; onError on
| 0.9.x and errorHandler on 0.8.x are the relevant reporting
| interfaces. This issue is fixed in @xmldom/xmldom versions 0.8.15
| and 0.9.12; no fixed version is available for xmldom.
CVE-2026-83612[4]:
| xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2
| Core) DOMParser and XMLSerializer module. From 0.9.0-beta.1 until
| 0.9.12, HTML-mode parsing through DOMParser.parseFromString()
| mishandles a mixed-case closing tag for the script, style, textarea,
| or title raw-text elements. parseHtmlSpecialContent, selected by
| isHTMLRawTextElement or isHTMLEscapableRawTextElement, uses a case-
| sensitive indexOf() and then calls substring() with a missing-close
| result of negative one, causing unstable parser progression and
| quadratic output amplification. A small untrusted text/html document
| can consequently consume disproportionate CPU and memory when parsed
| and serialized. This issue is fixed in @xmldom/xmldom version
| 0.9.12.
CVE-2026-83613[5]:
| 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,
| DOMHandler.startElement in lib/dom-parser.js inserts every parsed
| attribute through setAttributeNode, while NamedNodeMap.setNamedItem
| in lib/dom.js calls the linear getNamedItem or getNamedItemNS lookup
| for each insertion. A well-formed element with many distinct
| attributes therefore requires quadratic comparisons during
| DOMParser.parseFromString() and can stall a Node.js event loop
| before application validation. This issue is fixed in @xmldom/xmldom
| versions 0.8.15 and 0.9.12; no fixed version is available for
| xmldom.
CVE-2026-83614[6]:
| 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 versions 0.3.0 through
| 0.6.0, two independent quadratic paths can cause denial of service.
| In lib/sax.js, parseElementStartPart repeatedly rescans a malformed
| tag name to the next > during single-character recovery; in
| lib/dom.js, normalize() repeatedly removes and appends adjacent text
| nodes, causing quadratic reindexing and string rebuilding. The first
| path is reachable through default DOMParser.parseFromString()
| processing, while the second is also reachable through a direct
| normalize() call on a programmatically constructed DOM, and
| endDocument invokes that normalization after parsing. This issue is
| fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version
| is available for xmldom.
CVE-2026-83615[7]:
| 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 versions 0.1.5 through
| 0.6.0, appendElement in lib/sax.js uses _copy to clone the complete
| currentNSMap for each nested element that declares a new namespace
| prefix. Keeping every ancestor map live on the parse stack creates
| quadratic peak namespace-map storage, so a small highly compressible
| XML document can exhaust the process heap before application
| validation. This issue is fixed in @xmldom/xmldom versions 0.8.15
| and 0.9.12; no fixed version is available for xmldom.
CVE-2026-83616[8]:
| 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.createProcessingInstruction(target, data) in lib/dom.js
| accepts an unvalidated target, while the requireWellFormed: true
| serializer checks only for a colon and the reserved case-insensitive
| xml name on 0.9.x and performs no target check on 0.8.x. Because
| serialization emits <?target data?>, a target containing >, ?,
| whitespace, or another invalid XML-name character can break the
| processing-instruction boundary and inject XML structure. This issue
| is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed
| version is available for xmldom.
CVE-2026-83617[9]:
| xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2
| Core) DOMParser and XMLSerializer module. From 0.9.11 until 0.9.12,
| the requireWellFormed: true element and attribute name checks use
| the anchored QName_exact expression produced by reg() in
| lib/grammar.js, which inherits the multiline flag. A name with a
| valid first line followed by U+000A, U+000D, U+2028, or U+2029 and
| breakout markup therefore passes validation and is emitted verbatim
| in element start and end tags or attribute names. This bypasses the
| strict-serialization checks introduced for the earlier element-name
| and attribute-name injection advisories, while the default
| serialization path remains outside the strict guarantee. This issue
| is fixed in @xmldom/xmldom version 0.9.12.
CVE-2026-83618[10]:
| xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2
| Core) DOMParser and XMLSerializer module. From 0.9.10 until 0.9.12,
| the requireWellFormed: true serializer validates
| DocumentType.publicId and DocumentType.systemId with
| PubidLiteral_match and SystemLiteral_match expressions produced by
| reg() in lib/grammar.js, which inherit the multiline flag. A
| complete valid literal on the first line can therefore satisfy the
| matcher while U+000A, U+000D, U+2028, or U+2029 and breakout markup
| remain in the emitted <!DOCTYPE ...> declaration. This bypasses the
| strict-serialization mitigation for the earlier DocumentType
| injection advisory; creation and direct property assignment remain
| unvalidated by design. This issue is fixed in @xmldom/xmldom version
| 0.9.12.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-83608
https://www.cve.org/CVERecord?id=CVE-2026-83608
[1] https://security-tracker.debian.org/tracker/CVE-2026-83609
https://www.cve.org/CVERecord?id=CVE-2026-83609
[2] https://security-tracker.debian.org/tracker/CVE-2026-83610
https://www.cve.org/CVERecord?id=CVE-2026-83610
[3] https://security-tracker.debian.org/tracker/CVE-2026-83611
https://www.cve.org/CVERecord?id=CVE-2026-83611
[4] https://security-tracker.debian.org/tracker/CVE-2026-83612
https://www.cve.org/CVERecord?id=CVE-2026-83612
[5] https://security-tracker.debian.org/tracker/CVE-2026-83613
https://www.cve.org/CVERecord?id=CVE-2026-83613
[6] https://security-tracker.debian.org/tracker/CVE-2026-83614
https://www.cve.org/CVERecord?id=CVE-2026-83614
[7] https://security-tracker.debian.org/tracker/CVE-2026-83615
https://www.cve.org/CVERecord?id=CVE-2026-83615
[8] https://security-tracker.debian.org/tracker/CVE-2026-83616
https://www.cve.org/CVERecord?id=CVE-2026-83616
[9] https://security-tracker.debian.org/tracker/CVE-2026-83617
https://www.cve.org/CVERecord?id=CVE-2026-83617
[10] https://security-tracker.debian.org/tracker/CVE-2026-83618
https://www.cve.org/CVERecord?id=CVE-2026-83618
Regards,
Salvatore