CVE-2026-83605

xmldom, a pure-JavaScript W3C XML DOM parser and serializer distributed on npm as @xmldom/xmldom and the legacy xmldom package, does not validate the name passed to Element.setAttribute(), unlike Document.createAttribute(), which does enforce QName rules. An application that serializes a DOM built with attacker-controlled attribute names is vulnerable: XMLSerializer.serializeToString() emits those names verbatim, and even requireWellFormed: true did not catch the problem, so a crafted name can terminate the intended attribute and inject additional attributes, including event handlers, into output consumed by browsers; synthesized xmlns:PREFIX declarations hit the same unchecked-name boundary. An attacker gains integrity impact by tampering with the serialized markup — for example injecting event-handler attributes into documents rendered by a browser — with no confidentiality or availability impact per the CVSS 4.0 score of 8.7. Any application using @xmldom/xmldom prior to 0.8.14 or 0.9.11, or the legacy xmldom package in version 0.6.0 or earlier, is affected when it serializes attacker-influenced DOM state. No exploitation is known: EPSS is 0.3% (28th percentile), the CVE is not in CISA KEV, and no public proof-of-concept exists.

What to do: Upgrade to @xmldom/xmldom 0.8.14 (for the 0.8.x line) or 0.9.11 (for the 0.9.x line); the legacy xmldom package has no fixed release, so migrate to @xmldom/xmldom. Audit code paths where attacker-controlled strings reach Element.setAttribute() or synthesized xmlns declarations and are later serialized with XMLSerializer, and validate or sanitize attribute names as a mitigation where upgrading is not yet possible.