CVE-2026-83605: xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed

Summary

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.

Details

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 INVALIDCHARACTERERR (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.

Root Cause

1. setAttribute() calls createAttribute() (private, no validation) instead of createAttribute() (public, validates against QName). 2. The serializer trusts attribute names and emits them unescaped. 3. The serializer's requireWellFormed code path did not validate attribute names during serialization.

Proof of Concept

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

Demonstrating the validation gap

js // 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

Impact

Applications that use setAttribute() with any user-controlled portion of the attribute name are vulnerable to attribute injection attacks. This includes:

- Cross-Site Scripting (XSS): Injecting event handler attributes into HTML output consumed by browsers. - Security attribute override: Overriding security-relevant attributes such as integrity, nonce, sandbox, or Content-Security-Policy meta attributes. - Validation bypass: The public createAttribute() API validates while setAttribute() does not, creating an inconsistent security boundary that developers cannot rely on. - requireWellFormed bypass: Applications that adopted 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.

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

PoC — fixed path

js 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 }

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

Residual limitation

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.