Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An embedded line terminator bypasses the requireWellFormed serializer check for element and attribute names. The check was added to fix GHSA-w2rr-34g9-rvrj and GHSA-4w3w-2rp5-g8jm; a name whose first line is well-formed slips past it and is serialized verbatim, so the characters after the line terminator break out of the start/end tag or attribute. Callers who enabled requireWellFormed specifically to neutralize those name-injection issues remain exposed. Details xmldom builds every grammar production through a shared regexp builder that compiles with the m flag. The anchored full-string matcher used for element and attribute names, QNameexact = reg('^', QName, '$'), therefore inherits m. When it is applied as QNameexact.test(name) against an already-assembled node name, the m flag makes $ match at an interior line terminator, so the matcher accepts any value in which at least one line is a valid QName; the other lines are never constrained. A payload whose first line is a…
Recommended action: Upgrade to 0.9.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An embedded line terminator bypasses xmldom's always-on, WHATWG-mandated creation-time name validation. createElementNS, createAttributeNS, createDocumentType, and createAttribute should reject a malformed qualified name with InvalidCharacterError, but a name whose first line is well-formed slips through and enters the DOM. On serialization it is emitted verbatim, so the characters after the line terminator inject markup into the output. The injection reaches the default serialization path, and enabling requireWellFormed does not prevent it. Details createElementNS, createAttributeNS, and createDocumentType route through validateQualifiedName, and createAttribute performs the analogous check; each validates the name with g.QNameexact.test(name). QNameexact = reg('^', QName, '$') inherits the m flag from xmldom's shared regexp builder, so the matcher accepts any name whose first line is a valid QName and leaves the remaining lines unconstrained (see Root Cause). Root Cause 1.…
Recommended action: Upgrade to 0.9.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An embedded line terminator bypasses the requireWellFormed serializer check for a DocumentType's publicId and systemId. The check was added to fix GHSA-f6ww-3ggp-fr8h; an id whose first line is a valid literal slips past it and is emitted verbatim into the <!DOCTYPE … declaration, so the markup after the line terminator breaks out into the surrounding document. Callers who enabled requireWellFormed to neutralize DocumentType injection remain exposed. Details publicId and systemId are stored as raw values including their surrounding quotes, and the PubidLiteral/SystemLiteral productions include those quotes. The serializer validates them with g.PubidLiteralmatch.test(publicId) and g.SystemLiteralmatch.test(systemId), where both matchers are reg('^', …, '$') and inherit the m flag from xmldom's shared regexp builder. Under m, $ matches at an interior line terminator, so a value such as "valid pubid"\n"<!ENTITY … satisfies the matcher on its first line ("valid pubid" is a…
Recommended action: Upgrade to 0.9.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On the @xmldom/xmldom 0.8.x line, parsing an XML end tag whose name is followed by a long run of whitespace and then a non-whitespace character triggers quadratic-time regular-expression backtracking (ReDoS), so a single small crafted end tag stalls the Node.js event loop. It is reachable from DOMParser.parseFromString under default options, unauthenticated, before any validity check — an availability-only denial of service. The 0.9.x line is not affected. Details lib/sax.js (release-0.8.x, commit e5c1480) trims trailing whitespace from a captured end-tag name with an unanchored global regex: - lib/sax.js line 120: https://github.com/xmldom/xmldom/blob/e5c14802592685bb872c042c54c3f73758875c85/lib/sax.js#L120 Applied to a string shaped whitespace-run + one non-whitespace char (e.g. the content of an end tag </ … x), the engine must, for every starting position, extend [ws]+ to the end and then fail the $ anchor when the trailing non-whitespace char is present — classic O(n²)…
Recommended action: Upgrade to 0.8.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In HTML mode (text/html), a raw-text element (script, style, textarea, title) whose closing tag differs in case from its opening tag (e.g. </ScRiPt for <script) is mishandled by the parser, producing quadratic (O(n²)) output growth — a small crafted document parses and serializes into output orders of magnitude larger, exhausting CPU and memory. A modest input of tens of KB can therefore cause a denial of service in any service that parses untrusted HTML with xmldom. Only HTML mode is affected. Details The parser calls parseHtmlSpecialContent for each raw-text element in HTML mode, matched via isHTMLRawTextElement / isHTMLEscapableRawTextElement (so all four types — script, style, textarea, title — are in scope). It searches for the element's closing tag with source.indexOf('</' + tagName + '', elStartEnd), a byte-for-byte case-sensitive match. A mixed-case closing tag never matches, so the search returns -1, and the following source.substring(elStartEnd + 1, -1) extracts…
Recommended action: Upgrade to 0.9.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
@xmldom/xmldom's processing-instruction (PI) grammar regex exhibits quadratic-time backtracking (ReDoS) when parsing an unterminated processing instruction. A single small XML document containing <? + a target + a long run of whitespace and no closing ? forces the regular expression engine into O(n²) work, stalling the Node.js event loop. The input is parsed with DOMParser.parseFromString under default options, so it is reachable from unauthenticated, network-delivered XML (SOAP/SAML, webhooks, uploads, XML APIs). Details The PI production in lib/grammar.js compiles (flags mu) to: - lib/grammar.js line 261: https://github.com/xmldom/xmldom/blob/bb7a085dc5ba1eea3212388509b97bb4b4af32b9/lib/grammar.js#L261 In the optional tail (?:S+(Char?))?, both the greedy separator S+ and the lazy data Char? match XML whitespace. When the required trailing ? is absent, the engine must ultimately fail — but first it tries every partition of the whitespace run between S+ and Char?, which is…
Recommended action: Upgrade to 0.9.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.