CVE-2026-83607

CVE-2026-83607 is a high-severity security vulnerability in @xmldom/xmldom (npm), affecting versions >= 0.9.0, <= 0.9.10. It is fixed in 0.9.11, 0.8.14.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

xmldom: Element name injection via createElement() bypasses requireWellFormed

Document.createElement() in @xmldom/xmldom accepts arbitrary strings as the tagName parameter with zero validation. The serializer emits the tag name verbatim into XML/HTML output. Critically, the requireWellFormed: true serializer option, the recommended mitigation from CVE-2026-41672, CVE-2026-41674, and CVE-2026-34601, did NOT catch this, making it a bypass of the existing security controls.

An attacker who controls the element name string can inject arbitrary attributes (including event handlers) into the serialized output, leading to XSS when the output is consumed by a browser or downstream parser.

Details

Document.createElement() accepts any string as tagName and stores it directly on the element node without validation. When the document is later serialized via XMLSerializer.serializeToString(), the serializer emits the tagName verbatim into the output.

The XML specification requires element names to conform to the Name production. The existing createAttributeNS() and createElementNS() methods validate qualified names against an anchored name/QName pattern, but createElement() bypasses this entirely, and the requireWellFormed: true serializer path performed no element-name validation, rendering it ineffective against this vector.

Root Cause

  1. createElement() stores the raw tagName string without any validation.
  2. The serializer's requireWellFormed code path did not validate element names against the XML Name/QName production.
  3. The serializer emits tagName directly into angle brackets: <${tagName}...>.

Proof of Concept

const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');

const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);

// Inject an element whose "name" contains attributes with an XSS payload
const el = doc.createElement('img src=x onerror="alert(1)"');
doc.documentElement.appendChild(el);

const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// <root><img src=x onerror="alert(1)"/></root>
//
// A browser parsing this HTML will execute alert(1).
// requireWellFormed: true did NOT prevent the injection.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that
serialize untrusted DOM content should audit all serializeToString() call sites and add it.

When { requireWellFormed: true } is passed, the serializer now validates each element's serialized qualified name against the XML QName production and throws InvalidStateError before emitting the start tag. This also covers the namespace-prefix sub-vector: an invalid prefix surfaces either in the element qualified name (PREFIX:local) or in a synthesized xmlns:PREFIX declaration, and both are QName-checked.

Fixed under requireWellFormed: true in @xmldom/xmldom 0.9.11 and 0.8.14. Default serialization is unchanged.

PoC, fixed path

const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.appendChild(doc.createElement('img src=x onerror="alert(1)"'));

// Default (unchanged): verbatim, injection present
console.log(new XMLSerializer().serializeToString(doc));
// <root><img src=x onerror="alert(1)"/></root>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The element name "img src=x onerror="alert(1)"" is not a valid XML QName
}

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec defines a require well-formed flag whose default value is false. With the flag unset, the serializer emits element names verbatim, matching the XMLSerializer behavior of Chrome, Firefox, and Safari. Unconditionally throwing would be a behavioral breaking change with no spec justification; the opt-in requireWellFormed: true flag lets applications that require injection safety enable strict mode without breaking existing code.

Residual limitation

createElement(tagName) does not validate tagName at creation time. Enforcing an InvalidCharacterError for invalid names unconditionally at creation time is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without requireWellFormed: true), invalid element names are still emitted verbatim; applications that do not pass requireWellFormed: true remain exposed.

Creation-time validation is tracked in a public issue on the next breaking-release milestone (filed at publication, issue link to be added), targeting the next breaking release.

Impact

Applications that use @xmldom/xmldom to construct DOM trees and serialize them to XML/HTML are vulnerable to injection attacks if any part of an element name originates from user input. This includes:

  • Cross-Site Scripting (XSS): Injecting event handler attributes (onerror, onclick, etc.) into HTML output consumed by browsers.
  • XML injection: Breaking XML document structure by injecting closing tags, new elements, or processing instructions through the element name.
  • Security control bypass: Applications that adopted requireWellFormed: true as a mitigation for CVE-2026-41672 / 41674 / 34601 remained vulnerable through this vector.

@xmldom/xmldom can also be used inside browsers, where it mirrors the DOM API. Unlike the browser's createElement(), which rejects an invalid name with InvalidCharacterError, xmldom accepts it, developers may assume the same safety and skip validation.

Affected versions

@xmldom/xmldom (>= 0.9.0, <= 0.9.10) @xmldom/xmldom (>= 0.7.0, <= 0.8.13) xmldom (<= 0.6.0)

Security releases

@xmldom/xmldom → 0.9.11 (npm) @xmldom/xmldom → 0.8.14 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

@xmldom/xmldom to 0.9.11 or later; @xmldom/xmldom to 0.8.14 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-83607? CVE-2026-83607 is a high-severity security vulnerability in @xmldom/xmldom (npm), affecting versions >= 0.9.0, <= 0.9.10. It is fixed in 0.9.11, 0.8.14.
  2. Which packages are affected by CVE-2026-83607?
    • @xmldom/xmldom (npm) (versions >= 0.9.0, <= 0.9.10)
    • xmldom (npm) (versions <= 0.6.0)
  3. Is there a fix for CVE-2026-83607? Yes. CVE-2026-83607 is fixed in 0.9.11, 0.8.14. Upgrade to this version or later.
  4. Is CVE-2026-83607 exploitable, and should I be worried? Whether CVE-2026-83607 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-83607 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-83607?
    • Upgrade @xmldom/xmldom to 0.9.11 or later
    • Upgrade @xmldom/xmldom to 0.8.14 or later

Stop the waste.
Protect your environment with Kodem.