xmldom CVE-2026-83607

Exploitation requires three concurrent application-level conditions: (1) attacker-controlled input must be passed as the tagName argument to Document.createElement() without prior validation against the XML QName production; (2) the resulting DOM node must be serialized via XMLSerializer.serializeToString() - either with the default options or with requireWellFormed: true on an unpatched version, since the validation was missing in both paths; and (3) the serialized XML or HTML output must be delivered to and rendered by a web browser. The vulnerability does not affect server-side XML processing where output is never browser-rendered. The legacy xmldom package has no fix and remains permanently vulnerable. The @xmldom/xmldom package's requireWellFormed: true option now acts as a hard gate in patched versions, but relied on application opt-in and was silently broken before the fix.

The CVSS 4.0 score of 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N reflects the library's raw API surface - no authentication or user interaction is required to call createElement with a malicious string. However, real-world exploitability is conditional: an attacker must control a string that reaches createElement(), the application must then serialize the DOM, and the output must be rendered by a browser. These application-level preconditions introduce meaningful friction not captured in the provided vector. No EPSS score was supplied in the intelligence data, so exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalog, and no standalone public exploit code has been identified - however, the PR test cases (e.g., createElement('x><inject')) function as working proof-of-concept demonstrations embedded in the patch. The legacy xmldom package receives no fix, creating a permanent risk for projects that have not migrated to @xmldom/xmldom. The scope of impact is bounded by how widely applications expose attacker-controlled XML serialization to browsers, making this a significant but context-dependent risk rather than a universally exploitable critical flaw.

An attacker submits a crafted product name such as 'item><script>alert(1)</script><x' through an application form. The server-side code passes this value directly to document.createElement() in an xmldom-based XML builder, then serializes the document with XMLSerializer.serializeToString() and returns the result as an API response rendered by the browser. The injected script tag executes in the victim's browser context, enabling session theft or DOM manipulation.