Source: node-xmldom Version: 0.9.11-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
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
