CVE-2026-83607

What it actually does

Vulnerable xmldom implementations accept unvalidated element names in Document.createElement() and emit them verbatim via XMLSerializer.serializeToString(). The requireWellFormed:true path does not enforce XML QName rules or validate synthesized xmlns:PREFIX declarations, so attacker-controlled tag names can break out of the intended element and inject extra attributes, sibling elements, or processing instructions into serialized XML or HTML. When that output is later parsed or rendered in a browser, the injected markup can execute as cross-site scripting. Default createElement() and serialization remain permissive. Integrity of serialized documents is fully compromised; confidentiality and availability of the library itself are not directly affected.

Why it matters to the business

Applications that build or round-trip XML/HTML with attacker-influenced tag names can emit documents that no longer match the intended structure, leading to XSS in any browser-facing view, broken downstream XML consumers, and loss of trust in generated documents. Red Hat Developer Hub (rhdh) is among affected products. The issue has been public for about 32 days, is not listed in CISA KEV, and has no reported in-the-wild exploitation, but any internet-facing or multi-tenant surface that serializes untrusted names should still be treated as a high-integrity risk until patched. The unmaintained xmldom package has no fix, so remaining on it leaves a permanent XSS and document-integrity exposure.

How an attack unfolds

An attacker identifies a service that uses a vulnerable xmldom (or @xmldom/xmldom) build to create elements from names they can influence—for example user-supplied type names, imported XML, or plugin identifiers—and then serializes the document. They supply a tag name that is not a legal QName and that, when emitted verbatim, closes or extends the current element and inserts extra markup. Serialization does not reject the name even when requireWellFormed is enabled. The resulting string is returned to a client, stored, or forwarded. If a browser consumes it as HTML or XML, the injected content can run script in the victim origin or alter document structure for subsequent processors. No named threat actors or ransomware campaigns are associated with this CVE, and exploit maturity is none; the path is nonetheless straightforward wherever untrusted names reach createElement() and serializeToString().

How to fix it

Upgrade @xmldom/xmldom to 0.8.14 (0.8.x line) or 0.9.11 (0.9.x line). There is no fixed release for the legacy xmldom package; migrate off xmldom to a patched @xmldom/xmldom release. Red Hat Developer Hub customers should apply RHSA-2026:69248 (hub-rhel9:1789554285). After upgrading, keep requireWellFormed enabled and do not pass untrusted strings as element names; constrain names to a strict QName allowlist before createElement(). Rebuild and redeploy any containers or bundles that vendor the library.

How to confirm the fix worked

Inventory lockfiles, container images, and SBOM entries for xmldom@<=0.6.0, @xmldom/xmldom@<0.8.14 on the 0.8 line, and @xmldom/xmldom@<0.9.11 on the 0.9 line. Confirm production artifacts resolve to 0.8.14, 0.9.11, or later, and that Red Hat Developer Hub images match RHSA-2026:69248. In a staging environment, create elements only with legal QNames and confirm serializeToString() output stays well-formed; reject any remaining path that accepts arbitrary tag names. Regression-test XML/HTML emission used in browser views.

Typical attack path

1. Locate an application or component that uses vulnerable xmldom/@xmldom/xmldom and serializes documents built from external or user-controlled names.
2. Supply an illegal or breakout tag name (or xmlns prefix) through the input that reaches Document.createElement() or equivalent.
3. Trigger serialization via XMLSerializer.serializeToString() so the unvalidated name is written into the output document.
4. Cause a victim browser or downstream XML/HTML consumer to parse the serialized result.
5. Achieve script execution in the consuming origin or integrity violation of the document, depending on how the output is used.

How to detect it

There are no public in-the-wild campaigns, KEV listings, or named actors for this issue, so hunting should focus on residual vulnerable packages and suspicious serialized output rather than a known implant. Review package manager logs, container SBOMs, and node_modules for xmldom and @xmldom/xmldom versions below the fixed releases. On hosts running Red Hat Developer Hub, confirm whether RHSA-2026:69248 has been applied. Inspect application and reverse-proxy logs for XML/HTML responses generated after user-controlled type or tag fields, looking for serialized documents whose element names are not legal QNames or that contain unexpected processing instructions or extra attributes around serialization endpoints. Browser CSP/report-only logs and WAF XSS alerts on pages that consume that XML/HTML can indicate successful follow-on script execution. Preserve copies of generated XML from the relevant time window for well-formedness review.

• "xmldom": "0.6.0"
• "@xmldom/xmldom": "0.8.13"
• "@xmldom/xmldom": "0.9.10"
• node_modules/xmldom/
• node_modules/@xmldom/xmldom/package.json

What your security team should do

• Patch @xmldom/xmldom to 0.8.14 or 0.9.11 immediately and migrate off unmaintained xmldom; apply RHSA-2026:69248 for Red Hat Developer Hub.
• Treat remaining xmldom usage as unpatchable technical debt and schedule replacement.
• Find and constrain every createElement()/serializeToString() call site that accepts external names; enforce a QName allowlist.
• Prioritize internet-facing and browser-rendered XML/HTML outputs for review even though this CVE is not in KEV and has no known active exploitation.
• Add SCA/SBOM gates that fail builds on vulnerable xmldom versions and re-scan images after rebuild.