xmldom-xmldom

## Summary The `@xmldom/xmldom` serializer emits `DocumentType.name` verbatim into the `<!DOCTYPE …>` declaration with no well-formedness guard. GHSA-f6ww-3ggp-fr8h (CVE-2026-41674) hardened the serializer's `requireWellFormed` path for a DocumentType's sibling fields — `publicId`, `systemId`, and `internalSubset` — but it did **not** add any check for `name`. A `>` (or whitespace) in the name terminates the doctype declaration early, letting the remaining characters become sibling markup in the serialized output. Because `requireWellFormed: true` — the recommended mitigation for the prior x

CVE: CVE-2026-83608

## Summary 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 `createElementN

CVE: CVE-2026-83609

## Summary `Element.setAttribute()` in `@xmldom/xmldom` bypasses attribute name validation by calling the private `_createAttribute(name)` method, which performs no validation. The public `createAttribute()` method correctly validates names against an anchored `QName` pattern, but `setAttribute()` never uses it. The serializer escapes attribute *values* but trusts attribute *names*, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The `requireWellFormed: true` option did not catch this. ## Details `Element.setAttribute(name, value)` cre

CVE: CVE-2026-83605

## Summary xmldom's parser silently accepts a **not-well-formed end tag** whose valid name is followed by trailing content — e.g. `</a⏎junk>`. The element is closed, the trailing content is discarded, and no error is reported, even though the XML end-tag production allows only optional whitespace after the name and both Chromium and Firefox reject such input as `application/xml`. An application that relies on xmldom to reject not-well-formed input therefore receives a false "valid" result for a document the specification and browsers consider malformed. ## Details Across every affected vers

CVE: CVE-2026-83611

## Summary 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-tex

CVE: CVE-2026-83612

## Summary xmldom builds the attribute collection of every parsed element by inserting attributes one at a time into a DOM `NamedNodeMap`. Each insertion first performs a **linear scan of all already-inserted attributes** to enforce the DOM uniqueness rule (no two attributes with the same qualified name / namespace+local-name). Parsing an element that carries `M` distinct attributes therefore costs `1 + 2 + … + M = O(M²)` comparisons. Because the trigger is simply "one element with many attributes", the attack payload is a **fully well-formed XML document**. No malformed markup, no error rec

CVE: CVE-2026-83613

## Summary `xmldom`'s malformed-input **error-recovery path** has two quadratic-time (O(n²)) behaviors that a single crafted input triggers together, so a tiny, highly compressible document (tens of KB) stalls the Node.js event loop for multiple seconds. It is reachable from `DOMParser.parseFromString` under **default options** — i.e. from unauthenticated, network-delivered XML — making this an unauthenticated denial of service. One of the two behaviors, the `normalize()` adjacent-text merge, is **additionally reachable programmatically** — via a plain `normalize()` call on a DOM built with a

CVE: CVE-2026-83614

## Summary When an element declares a namespace prefix, xmldom copies the entire in-scope namespace map into a fresh object and keeps that copy on the element while it is open on the parse stack. A crafted document that nests N elements, each declaring one unique prefix, therefore drives the parser to hold on the order of N(N+1)/2 = **O(N²) namespace-map entries at its peak**, so a small, highly compressible input exhausts the heap. Parsing runs under default options on untrusted, network-delivered XML, so a sub-megabyte payload can OOM-crash the process before any application-level validatio

CVE: CVE-2026-83615

## Summary `Document.createProcessingInstruction()` in `@xmldom/xmldom` performs no validation on the `target` parameter. The `requireWellFormed: true` serializer option validates only for `:` in the target and a case-insensitive `xml` prefix, but does not check for `>` characters. A `>` in the target breaks the processing instruction boundary (`<?...?>`), allowing injection of arbitrary content into the serialized XML output. ## Details `Document.createProcessingInstruction(target, data)` at `lib/dom.js` around line 2413 accepts any string as the `target` parameter and stores it on the PI

CVE: CVE-2026-83616

## Summary `@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`

CVE: CVE-2026-83606