| Package | Affected versions | Patched versions |
|---|---|---|
| @xmldom/xmldom | ≥ 0.7.0, < 0.8.15≥ 0.9.0, < 0.9.12 | 0.8.150.9.12 |
| xmldom | ≤ 0.6.0 |
Document.createProcessingInstruction() in @xmldom/xmldom performs no validation on the target parameter. The requireWellFormed: true serializer option validates only for : in the target and a case-insensitive xml prefix, but does not check for > characters. A > in the target breaks the processing instruction boundary (<?...?>), allowing injection of arbitrary content into the serialized XML output.
Document.createProcessingInstruction(target, data) at lib/dom.js around line 2413 accepts any string as the target parameter and stores it on the PI node without validation.
During serialization, the requireWellFormed code path (around line 3286) performs two checks on PI targets:
: (namespace prefix check)xml case-insensitively (reserved prefix)However, it does NOT validate that the target conforms to the XML Name production, and critically does NOT check for > characters. Since processing instructions are serialized as <?target data?>, a > in the target prematurely closes the PI, causing the remaining content to be interpreted as document content by any downstream XML parser.
createProcessingInstruction() performs no validation on targetrequireWellFormed check is incomplete -- it only checks for : and xml, missing characters that break PI syntax (>, ?, whitespace)<?${target} ${data}?>const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// PI target containing > breaks the PI boundary
const pi = doc.createProcessingInstruction('a>', 'data');
doc.documentElement.appendChild(pi);
const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// Output: <root><?a> data?></root>
//
// The > in the target closes the PI prematurely.
// A downstream XML parser sees:
// - Processing instruction: <?a?> (target "a", no data)
// - Text content: " data?>"
//
// requireWellFormed: true did NOT prevent the injection.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeconst pi2 = doc.createProcessingInstruction(
'a?><script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script><?b',
''
);
doc.documentElement.appendChild(pi2);
const output2 = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output2);
// Output includes:
// <?a?><script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script><?b ?>
//
// The injected <script> element is valid XHTML that a browser would execute.
Applications that create processing instructions with user-controlled target strings and serialize the result are vulnerable to XML injection. This enables:
Under requireWellFormed, the serializer validates a processing-instruction target as an XML NCName (a Name with no colon) and rejects a case-insensitive xml, throwing InvalidStateError when the target is ill-formed — so a >, ?, or whitespace in the target is now refused.
On 0.9.12 this replaces an earlier check that already rejected a colon or xml, so the no-colon rule is preserved.
0.8.15 had no processing-instruction target check at all, so the whole target validation is new there.
Non-breaking and opt-in. See the XML Name production.
⚠ 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 allserializeToString()call sites and add it.
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// PI target containing > breaks the PI boundary
const pi = doc.createProcessingInstruction('a>', 'data');
doc.documentElement.appendChild(pi);
// Default path: emits the ill-formed target verbatim.
console.log(serializer.serializeToString(doc));
// Output: <root><?a> data?></root>
// Opt-in path: the target check now rejects the break-out character.
try {
serializer.serializeToString(doc, { requireWellFormed: true });
} catch (e) {
console.log(e.name); // InvalidStateError
}
W3C DOM Parsing's require-well-formed flag defaults to false, and the browser XMLSerializer emits the target verbatim in that default mode. Unconditionally throwing on an ill-formed PI target would diverge from that platform behavior and would be an unjustified breaking change, so the stricter validation is gated behind { requireWellFormed: true }. (See the W3C XML Name production and XML Processing Instructions.)
The default serialization path still emits the ill-formed target verbatim -- only the opt-in requireWellFormed path is protected. Creation-time validation of the target in createProcessingInstruction() is breaking and is deferred to the next breaking release, tracked at xmldom/xmldom#1073.