CVE-2026-83605: xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.14 and 0.9.11, and in xmldom version 0.6.0 and earlier, Element.setAttribute() calls the private createAttribute(name) path without validating the attribute name, while Document.createAttribute(name) validates against QName. XMLSerializer.serializeToString() emits attribute names verbatim, and requireWellFormed: true did not validate them, so a crafted name can terminate the intended attribute and inject additional attributes, including event handlers, into browser-consumed output; synthesized xmlns:PREFIX declarations expose the same unchecked-name boundary. This issue is fixed in @xmldom/xmldom versions 0.8.14 and 0.9.11; no fixed version is available for xmldom.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@xmldom/xmldomto a version that resolves this vulnerability.Fixed in 0.8.14 - Upgrade
Upgrade
@xmldom/xmldomto a version that resolves this vulnerability.Fixed in 0.9.11
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Applications are exposed when they use Element.setAttribute() with attacker-influenced attribute names and serialize the resulting DOM to XML that is consumed by a browser. The impact includes injection of additional attributes, such as event handlers, into that output.
Does enabling requireWellFormed prevent exploitation?
No. In affected versions, requireWellFormed: true did not validate attribute names emitted by XMLSerializer.serializeToString(), so it does not block this injection path.
What versions should be remediated?
For @xmldom/xmldom, upgrade to 0.8.14 or 0.9.11. xmldom has no fixed version available, so users of that package need to move to a maintained fixed package or otherwise ensure untrusted values cannot be used as attribute names.
How can I identify potentially affected code?
Review uses of Element.setAttribute() where the first argument can be influenced by external input, especially where the DOM is later passed to XMLSerializer.serializeToString() and rendered or otherwise consumed by a browser. Also review code that synthesizes xmlns:PREFIX declarations from unchecked names.