| Package | Affected versions | Patched versions |
|---|---|---|
| @xmldom/xmldom | ≥ 0.7.0, < 0.8.14≥ 0.9.0, < 0.9.11 | 0.8.140.9.11 |
| xmldom | ≤ 0.6.0 |
Element.setAttribute() in @xmldom/xmldom bypasses attribute name validation by calling the private _createAttribute(name) method, which performs no validation. The public createAttribute() method correctly validates names against an anchored QName pattern, but setAttribute() never uses it. The serializer escapes attribute values but trusts attribute names, allowing an attacker to inject additional attributes (including event handlers) into serialized output. The requireWellFormed: true option did not catch this.
Element.setAttribute(name, value) creates attribute nodes by calling the private _createAttribute(name) method, which performs no validation on the name parameter. In contrast, the public Document.createAttribute(name) method validates the name against the QName production before creating the attribute node.
The result is a two-tier validation system where the most commonly used API (setAttribute) takes the unvalidated path:
doc.createAttribute("bad name") — throws INVALID_CHARACTER_ERR (correct).el.setAttribute("bad name", "value") — succeeds silently (vulnerable).The serializer emits attribute names verbatim into the output. Because attribute values ARE escaped (quotes, ampersands, etc.), the injection must occur through the name. An attacker can terminate the current attribute and inject new ones by including quote and space characters in the attribute name.
setAttribute() calls _createAttribute() (private, no validation) instead of createAttribute() (public, validates against QName).requireWellFormed code path did not validate attribute names during serialization.const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const impl = new DOMImplementation();
const serializer = new XMLSerializer();
const doc = impl.createDocument(null, 'root', null);
// The attribute name contains a closing quote, a space, and a new attribute
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
const output = serializer.serializeToString(doc, { requireWellFormed: true });
console.log(output);
// <root class="safe" onclick="alert(1)"/>
//
// The single setAttribute() call produced TWO attributes:
// 1. class="safe"
// 2. onclick="alert(1)"
//
// 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 free// Public createAttribute correctly rejects invalid names:
try {
doc.createAttribute('class="safe" onclick');
} catch (e) {
console.log('createAttribute rejects:', e.message);
}
// But setAttribute (which uses _createAttribute) accepts the same input:
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
// No error thrown
Applications that use setAttribute() with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:
integrity, nonce, sandbox, or Content-Security-Policy meta attributes.createAttribute() API validates while setAttribute() does not, creating an inconsistent security boundary that developers cannot rely on.requireWellFormed: true as a mitigation for prior CVEs remained vulnerable.@xmldom/xmldom can also be used inside browsers, where it mirrors the DOM API. Unlike the browser's setAttribute(), which rejects an invalid attribute name with InvalidCharacterError, xmldom accepts it — developers may assume the same safety and skip validation.
⚠ 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.
When { requireWellFormed: true } is passed, the serializer now validates each serialized attribute's qualified name against the XML QName production and throws InvalidStateError before emitting it. This covers ordinary attribute names and synthesized xmlns:PREFIX namespace declarations (the namespace-prefix sub-vector).
Fixed under requireWellFormed: true in @xmldom/xmldom 0.9.11 and 0.8.14. Default serialization is unchanged.
const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom');
const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.setAttribute('class="safe" onclick', 'alert(1)');
// Default (unchanged): verbatim — injection present
console.log(new XMLSerializer().serializeToString(doc));
// <root class="safe" onclick="alert(1)"/>
// Opt-in guard: throws InvalidStateError before serializing
try {
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
console.log(e.name, e.message);
// InvalidStateError: The attribute name "class="safe" onclick" is not a valid XML QName
}
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 attribute 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.
setAttribute(name, value) does not validate name at creation time (unlike the public createAttribute(), which already does). Making setAttribute() reject invalid names unconditionally is a breaking change and is deferred to the next breaking release. When the default serialization path is used (without requireWellFormed: true), attribute names set via setAttribute() 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.