xmldom CVE-2026-83609

Exploitation requires that attacker-controlled data reaches one of four specific DOM creation APIs: createElementNS, createAttributeNS, createDocumentType, or createAttribute. The attacker-supplied name must contain at least one ECMAScript line terminator - LF (U+000A), CR (U+000D), LINE SEPARATOR (U+2028), or PARAGRAPH SEPARATOR (U+2029) - followed by the injected XML payload. Both the default serialization path and requireWellFormed: true are vulnerable in affected versions. Applications that only parse fixed or fully-trusted XML and never construct element or attribute names from external input are not exploitable. The CVSS vector AV:N/AC:L/PR:N/UI:N indicates no authentication, no special network position, and no user interaction are required when the vulnerable APIs are reachable from external input.

The CVSS 4.0 base score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N) correctly reflects that no authentication, no special network position, and no attack prerequisites beyond API reachability are needed. Real-world exploitability is context-dependent: only applications that build XML element or attribute names from attacker-controlled input are at risk; those that only parse static or trusted XML are not meaningfully exposed. The impact is strictly integrity-only - confidentiality and availability are unaffected. No CISA KEV listing and no POC were identified at time of analysis, so active exploitation is not confirmed. EPSS data is absent from the provided intelligence. Despite the absence of confirmed exploitation, applications using xmldom to construct SAML assertions, SOAP envelopes, signed XML, or any output consumed by downstream systems should treat this as a high-priority patch: the zero-prerequisite CVSS vector and the breadth of xmldom's npm install base represent meaningful exposure if exploitation techniques become public.

An attacker sends an HTTP request to a Node.js application that constructs XML using xmldom with a user-supplied element name such as 'validName ></validName><injected>' - the embedded LF causes the multiline QName regex to accept 'validName' as valid while ignoring the trailing injection. When the application serializes and forwards the resulting document, for example as a SAML assertion or a SOAP request body, the injected markup appears verbatim in the output and can alter document structure, bypass downstream schema validation, or poison a security-sensitive XML consumer. No public POC has been identified at time of analysis.