CVE-2026-83608

What it actually does

xmldom fails to enforce the XML Name production on DocumentType.name during serialization, including on the requireWellFormed path. A name containing '>' or whitespace can close the emitted DOCTYPE declaration early so that additional sibling markup is written into the serialized document. This is a document-integrity failure (high integrity impact) with no direct confidentiality or availability impact on the parser itself.

Why it matters to the business

Applications that serialize XML with a vulnerable xmldom build can emit documents whose structure is not what the producer intended. Downstream parsers, browsers, signature verifiers, and configuration loaders may treat injected markup as real content, undermining integrity checks and XML-based workflows. Red Hat Developer Hub is among affected products. The unscoped xmldom package has no patch, so remaining dependents stay exposed until they migrate to the scoped package. The issue has been public for about a month, is not on CISA KEV, is not associated with ransomware, and currently has no reported exploit maturity, which lowers mass-exploitation urgency but does not reduce the need to patch XML-serializing services.

How an attack unfolds

An attacker who can influence DocumentType creation or the DocumentType.name property supplies a value that is not a legal XML Name. On the 0.8.x and unscoped lines this can occur through createDocumentType(); on every affected line a direct write to DocumentType.name also works. Default and legacy creation-time behavior remain permissive, and the strict path still emits the name verbatim. When the document is serialized, characters that terminate a DOCTYPE declaration cause any remaining content to appear as sibling markup. A later consumer that parses or renders that XML then treats the injected structure as part of the document. The library requires no authentication; whether this is remotely reachable depends on whether the host application exposes DocumentType construction or mutation to untrusted input. No named threat actors or in-the-wild campaigns are reported.

How to fix it

Upgrade @xmldom/xmldom to 0.8.15 on the 0.8 line or 0.9.12 on the 0.9 line. There is no fixed version for unscoped xmldom (0.6.0 and earlier); migrate those dependencies to a patched @xmldom/xmldom release. For Red Hat Developer Hub, apply RHSA-2026:69248 and deploy hub-rhel9:1789554285 or later. Rebuild and redeploy every artifact that bundles the library. Until patched, do not let untrusted input reach createDocumentType or DocumentType.name, and do not serialize untrusted DocumentType nodes.

How to confirm the fix worked

Inventory lockfiles, SBOM data, and container images for xmldom and @xmldom/xmldom. Confirm @xmldom/xmldom is 0.8.15+ or 0.9.12+ and that unscoped xmldom has been removed. For RHDH, verify the image corresponding to RHSA-2026:69248 (hub-rhel9:1789554285 or later). Search application code for createDocumentType and assignments to DocumentType.name. In staging, serialize only well-formed DocumentType names and confirm output stays well-formed; confirm the patched library no longer emits illegal names verbatim under requireWellFormed.

Typical attack path

1. Identify an application that serializes XML with a vulnerable xmldom or @xmldom/xmldom release and that lets untrusted input influence DocumentType creation or DocumentType.name.
2. Cause a DocumentType name that is not a valid XML Name to be set, using characters that end a DOCTYPE declaration at serialization time.
3. Trigger serialization through an export, HTTP response, signing step, or persistence path.
4. Deliver the serialized document to a downstream parser, browser, or verifier so the injected sibling markup is interpreted as real structure.
5. Abuse the resulting integrity break (unexpected elements, broken signatures, or further content injection) in the consuming component.

How to detect it

This is a library serialization flaw; abuse shows up in generated XML and in application logs around DocumentType handling, not as a distinct malware family. Review XML outputs, exports, and HTTP responses produced since publication for DOCTYPE declarations whose name is not a valid XML Name or that are immediately followed by unexpected sibling markup. Hunt application and debug logs for createDocumentType usage and for downstream parser errors on xmldom output. Treat presence of xmldom 0.6.0 or earlier, or @xmldom/xmldom below 0.8.15 or 0.9.12, as exposure rather than proof of compromise. No named actors or ransomware use are associated, and exploit maturity is none, so prioritize integrity anomalies in XML pipelines over signature-based malware hunts.

What your security team should do

• Patch or rebuild all services using @xmldom/xmldom below 0.8.15 or 0.9.12, and replace unscoped xmldom with a patched scoped release.
• Apply RHSA-2026:69248 to Red Hat Developer Hub and confirm hub-rhel9:1789554285 or later is deployed.
• Review application paths that construct or mutate DocumentType from request data, files, or plugins and treat those as high-priority code review items.
• Stop serializing XML from untrusted DocumentType input until patched builds are confirmed.
• Track this as integrity-focused XML injection: not in KEV and no known exploit maturity, but public for over 30 days, so keep aggressive SLAs for internet-facing XML emitters.