Summary
xmldom: requireWellFormed DocType publicId/systemId validation is bypassable via an embedded line terminator
An embedded line terminator bypasses the requireWellFormed serializer check for a DocumentType's
publicId and systemId. The check was added to fix GHSA-f6ww-3ggp-fr8h; an id whose first line is a
valid literal slips past it and is emitted verbatim into the <!DOCTYPE …> declaration, so the markup
after the line terminator breaks out into the surrounding document. Callers who enabledrequireWellFormed to neutralize DocumentType injection remain exposed.
Details
publicId and systemId are stored as raw values including their surrounding quotes, and thePubidLiteral/SystemLiteral productions include those quotes. The serializer validates them withg.PubidLiteral_match.test(publicId) and g.SystemLiteral_match.test(systemId), where both matchers
are reg('^', …, '$') and inherit the m flag from xmldom's shared regexp builder. Under m, $
matches at an interior line terminator, so a value such as "valid pubid"\n"><!ENTITY …> satisfies
the matcher on its first line ("valid pubid" is a complete PubidLiteral) and the whole value ,
including the post-newline breakout, is emitted after PUBLIC/SYSTEM.
Root Cause
- A shared regexp builder compiles anchored productions with the
mflag. ^…$undermare line anchors, not string anchors.- A full-string validator built on such a production (
.test()) accepts any string with one
conforming line, so a complete, valid literal on the first line passes even though a line terminator
and breakout markup follow.PubidCharexcluding</>does not prevent it, the breakout is
appended after the literal, not embedded inside it.
The triggering line terminators are the ECMAScript LineTerminator set: U+000A, U+000D, U+2028, U+2029.
Affected Versions
Only @xmldom/xmldom 0.9.x is affected. The vulnerable matchers are built by lib/grammar.js'sm-flagged reg() builder, and the DocType publicId/systemId requireWellFormed check that
consumes them was introduced in 0.9.10 (the GHSA-f6ww-3ggp-fr8h fix); 0.9.10 and 0.9.11 carry it.0.8.x performs the same requireWellFormed check with inline, non-m regular expressions and is not
affected. The unscoped xmldom package has no grammar.js and no requireWellFormed serializer, so
there is no check to bypass.
Proof of Concept
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
// publicId: complete literal on line 1, then newline + breakout
const dt = impl.createDocumentType('html', '"valid pubid"\n"><!ENTITY xxe SYSTEM "file:///etc/passwd">', '');
const doc = impl.createDocument(null, 'root', dt);
console.log(new XMLSerializer().serializeToString(doc, { requireWellFormed: true }));
// Observed (no throw):
// <!DOCTYPE html PUBLIC "valid pubid"
// "><!ENTITY xxe SYSTEM "file:///etc/passwd">><root/>
// Expected: InvalidStateError (publicId is not a valid PubidLiteral).
// Control: a single-line invalid publicId ("no-surrounding-quotes<>") DOES throw InvalidStateError,
// confirming the check is active and specifically bypassed by the line terminator.
Fix Applied
The anchored PubidLiteral/SystemLiteral validators used by the requireWellFormed
serializer no longer treat an interior line terminator as satisfying the $ anchor, so a publicId
or systemId containing any ECMAScript LineTerminator (U+000A, U+000D, U+2028, U+2029) is rejected
with InvalidStateError. Valid single-line identifiers serialize unchanged, and the default
serialization path is unaffected.
⚠ 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 impl = new DOMImplementation();
const dt = impl.createDocumentType('html', '"valid pubid"\n"><!ENTITY xxe SYSTEM "file:///etc/passwd">', '');
const doc = impl.createDocument(null, 'root', dt);
// Default path (requireWellFormed off), unchanged, still emits verbatim:
console.log(new XMLSerializer().serializeToString(doc));
// <!DOCTYPE html PUBLIC "valid pubid"
// "><!ENTITY xxe SYSTEM "file:///etc/passwd">><root/>
// Opt-in path, now throws instead of emitting the breakout:
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
// InvalidStateError: DocumentType publicId is not a valid PubidLiteral
Why the default stays verbatim
The W3C DOM Parsing "require well-formed" flag defaults to false, and a browser XMLSerializer emits
the DOCTYPE verbatim. Unconditionally throwing on a malformed publicId/systemId would be an
unjustified breaking change to the default path, so the fix tightens only the opt-inrequireWellFormed validator, matching browser and spec defaults.
Residual limitation
The guarantee holds only for callers that pass { requireWellFormed: true }; the default
serialization path still emits publicId/systemId verbatim. publicId and systemId are not
validated at creation (createDocumentType) or on direct property assignment
(documentType.publicId = …), the WHATWG DOM specification places no well-formedness constraint on
these fields at creation time, so the serializer is the spec-aligned enforcement point.
Impact
- Bypass of the GHSA-f6ww-3ggp-fr8h mitigation. Applications that adopted
requireWellFormed: trueto neutralize DocumentType injection remain exposed. - XML structure injection into the DOCTYPE, including injected markup / entity declarations after
the public or system identifier.
Affected versions
Security releases
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
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-83618? CVE-2026-83618 is a high-severity security vulnerability in @xmldom/xmldom (npm), affecting versions >= 0.9.10, <= 0.9.11. It is fixed in 0.9.12.
- Which versions of @xmldom/xmldom are affected by CVE-2026-83618? @xmldom/xmldom (npm) versions >= 0.9.10, <= 0.9.11 is affected.
- Is there a fix for CVE-2026-83618? Yes. CVE-2026-83618 is fixed in 0.9.12. Upgrade to this version or later.
- Is CVE-2026-83618 exploitable, and should I be worried? Whether CVE-2026-83618 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
- What actually determines whether CVE-2026-83618 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.
- How do I fix CVE-2026-83618? Upgrade
@xmldom/xmldomto 0.9.12 or later.