GHSA-4w3w-2rp5-g8jm xmldom: Attribute name injection via setAttribute() bypasses requireWellFormed

• npm @xmldom/xmldom: >= 0.9.0, < 0.9.11 → fixed in 0.9.11 • npm @xmldom/xmldom: >= 0.7.0, < 0.8.14 → fixed in 0.8.14 • npm xmldom: <= 0.6.0 (no fix yet)

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 `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. 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); // // // 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)); // // 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.