GHSA-3px3-54cx-rmw9: XSS

Published Sep 8, 2026
·
Updated

Summary

An embedded line terminator bypasses xmldom's always-on, WHATWG-mandated creation-time name validation. createElementNS, createAttributeNS, createDocumentType, and createAttribute should reject a malformed qualified name with InvalidCharacterError, but a name whose first line is well-formed slips through and enters the DOM. On serialization it is emitted verbatim, so the characters after the line terminator inject markup into the output. The injection reaches the default serialization path, and enabling requireWellFormed does not prevent it.

Details

createElementNS, createAttributeNS, and createDocumentType route through validateQualifiedName, and createAttribute performs the analogous check; each validates the name with g.QNameexact.test(name). QNameexact = reg('^', QName, '$') inherits the m flag from xmldom's shared regexp builder, so the matcher accepts any name whose first line is a valid QName and leaves the remaining lines unconstrained (see Root Cause).

Root Cause

1. A shared regexp builder compiles anchored productions with the m flag. 2. ^…$ under m are line anchors, not string anchors. 3. validateQualifiedName / createAttribute validate with .test() against such a production, so a line terminator followed by breakout markup passes and the malformed name is stored.

The triggering line terminators are the ECMAScript LineTerminator set: U+000A, U+000D, U+2028, U+2029.

Proof of Concept

js const { DOMImplementation, XMLSerializer } = require('@xmldom/xmldom'); const impl = new DOMImplementation();

const doc = impl.createDocument('urn:x', 'root', null); const el = doc.createElementNS('urn:x', 'a\n><script>x</script'); // ACCEPTED (no throw) doc.documentElement.appendChild(el);

// DEFAULT serialization — requireWellFormed NOT set: console.log(new XMLSerializer().serializeToString(doc)); // Observed: <root xmlns="urn:x"><a // ><script>x</script/></root> <-- injected element on the default path // Control: createElementNS('urn:x', 'bad>name') throws InvalidCharacterError, confirming the check is // active and specifically bypassed by the line terminator.

Impact

- Bypass of the always-on WHATWG creation-time name validation (InvalidCharacterError): a malformed name the standard requires be rejected at creation is instead admitted to the DOM. - Markup / structure injection. An application relying on the create APIs to reject malformed names (the standard behavior) as a trust boundary is exposed; where the serialized output reaches an HTML context, downstream XSS. - No serializer option mitigates it. The admitted name is emitted verbatim under both the default path and requireWellFormed: true — the strict serializer shares the same m-flagged blind spot (the subject of the sibling serializer advisories) — so the bypassed creation-time check was the only layer that could have stopped it. Demonstrated for all four create sites in poccreationstrictserializationbypass.cjs.

Fix Applied

createElementNS, createAttributeNS, createDocumentType, and createAttribute now reject a name containing a line terminator with InvalidCharacterError — the same result they already give for other malformed names — because name validation now applies to the whole string. The requireWellFormed serializer's name checks are corrected by the same change. The fix is non-breaking: such a name was already invalid, and no previously-accepted well-formed name is affected.

Affected Software

1 affected componentFixes available
npm/@xmldom/xmldom>=0.9.0<=0.9.11
0.9.12

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@xmldom/xmldom to a version that resolves this vulnerability.

    Fixed in 0.9.12
  2. Configuration

    Ensure the strict serializer name checks are corrected by the same fix: `requireWellFormed: true` should not allow malformed qualified names containing line terminators (U+000A, U+000D, U+2028, U+2029) to be admitted and emitted verbatim.

    xmldom XMLSerializer (requireWellFormed) requireWellFormed = true
  3. Configuration

    Verify that `createElementNS`, `createAttributeNS`, `createDocumentType`, and `createAttribute` route name checks through `validateQualifiedName` and use `g.QName_exact.test(name)` so that names containing line terminators are rejected with `InvalidCharacterError` instead of being stored and later emitted on serialization.

    xmldom DOMImplementation / Document create* APIs createElementNS/createAttributeNS/createDocumentType/createAttribute validation = reject

Event History

Sep 8, 2026
Advisory Published
via GitHub·09:02 PM
Data Sourced
via GitHub·09:02 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which applications are exposed in practice?

Applications are exposed when attacker-controlled input can influence names supplied to xmldom's createElementNS, createAttributeNS, createDocumentType, or createAttribute APIs and the resulting DOM is serialized. The serialized output can contain injected markup after an embedded line terminator.

2

What input is required to exploit the issue?

An attacker needs to provide a qualified name whose first line is valid but whose later content follows an embedded line terminator. The validation accepts the first line while leaving the remaining lines unconstrained.

3

Does enabling requireWellFormed prevent exploitation?

No. The issue reaches the default serialization path, and requireWellFormed does not prevent the injected characters from being emitted.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203