CVE-2026-83617

CVE-2026-83617 is a high-severity security vulnerability in @xmldom/xmldom (npm), affecting versions = 0.9.11. It is fixed in 0.9.12.

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: requireWellFormed element/attribute name validation is bypassable via an embedded line terminator

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, QName_exact = reg('^', QName, '$'), therefore inherits m. When it is applied as QName_exact.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 valid QName, followed by a line terminator and breakout
markup, is what yields a working injection.

The serializer emits the accepted name verbatim into element start/end tags and attribute names, so
the bytes after the line terminator break out of the intended syntactic position. The check is
reached whenever a caller serializes, with requireWellFormed: true, a node whose name was set
through programmatic DOM construction (createElement, createElementNS, createAttribute,
createAttributeNS) with attacker-influenced input.

Root Cause

  1. A shared regexp builder compiles anchored productions with the m flag.
  2. ^…$ under m are line anchors, not string anchors.
  3. A full-string validator built on such a production (.test()) accepts any string with one
    conforming line, so a line terminator followed by breakout markup passes.

The triggering line terminators are the ECMAScript LineTerminator set: U+000A, U+000D, U+2028, U+2029.

Proof of Concept

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

// Element name carrying an embedded line terminator + breakout markup:
const doc = new DOMImplementation().createDocument(null, 'root', null);
const el = doc.createElement('a\n><script>alert(1)</script');
doc.documentElement.appendChild(el);

// Caller opted into well-formed serialization, expecting invalid names to be rejected:
console.log(new XMLSerializer().serializeToString(doc, { requireWellFormed: true }));
// Observed on the affected version: NO throw; the output contains the injected `><script>…`
// breakout, because the name's first line ("a") satisfies the m-anchored QName check.
// Expected: InvalidStateError (the name is not a valid XML QName).

// Control, a single-line invalid name IS correctly rejected, proving the check is active and
// that only the line terminator defeats it:
const ctrl = new DOMImplementation().createDocument(null, 'root', null);
ctrl.documentElement.appendChild(ctrl.createElement('a b'));
new XMLSerializer().serializeToString(ctrl, { requireWellFormed: true });
// => throws InvalidStateError: The element name "a b" is not a valid XML QName

Fix Applied

The anchored XML Name/QName validators used by the requireWellFormed serializer no
longer treat interior line terminators as satisfying the anchors, so a name is validated against the
whole string. A name containing a line terminator is rejected with InvalidStateError, closing the
bypass for element and attribute names. The default serialization path is unchanged.

⚠ 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.

Proof of Concept - fixed path

const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMImplementation().createDocument(null, 'root', null);
const el = doc.createElement('a\n><script>alert(1)</script');
doc.documentElement.appendChild(el);

// Default path (require-well-formed off), unchanged, still emits the name verbatim,
// so the `><script>…` bytes break out of the start tag:
new XMLSerializer().serializeToString(doc);

// Opted-in path, now rejected:
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
// throws InvalidStateError: The element name "a\n><script>alert(1)</script" is not a valid XML QName

Why the default stays verbatim

The W3C DOM Parsing require-well-formed flag defaults to false, and browser XMLSerializer emits
names verbatim when it is unset. Throwing unconditionally would be an unjustified breaking change, so
the check stays gated on the caller opting in with { requireWellFormed: true }.

Residual limitation

The default serialization path (no requireWellFormed) still emits names verbatim by design (above).
Names introduced through createElement / setAttribute are never validated at creation, those APIs
store the name unchecked by design, so the opt-in serializer check remains the only guard on that
path.

Impact

  • Bypass of a previously shipped security mitigation. Applications that adopted
    requireWellFormed: true specifically to neutralize GHSA-w2rr-34g9-rvrj / GHSA-4w3w-2rp5-g8jm
    remain exposed to element/attribute name injection.
  • XML / markup structure injection, and, where the serialized output is placed into an HTML
    context, downstream XSS.

Affected versions

@xmldom/xmldom (= 0.9.11)

Security releases

@xmldom/xmldom → 0.9.12 (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 @xmldom/xmldom to 0.9.12 or later to resolve this vulnerability.

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

Frequently Asked Questions

  1. What is CVE-2026-83617? CVE-2026-83617 is a high-severity security vulnerability in @xmldom/xmldom (npm), affecting versions = 0.9.11. It is fixed in 0.9.12.
  2. Which versions of @xmldom/xmldom are affected by CVE-2026-83617? @xmldom/xmldom (npm) versions = 0.9.11 is affected.
  3. Is there a fix for CVE-2026-83617? Yes. CVE-2026-83617 is fixed in 0.9.12. Upgrade to this version or later.
  4. Is CVE-2026-83617 exploitable, and should I be worried? Whether CVE-2026-83617 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-83617 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-83617? Upgrade @xmldom/xmldom to 0.9.12 or later.

Stop the waste.
Protect your environment with Kodem.