CVE-2026-83610

What it actually does

Vulnerable xmldom builds accept an invalid name in Document.createEntityReference() and the ENTITY_REFERENCE_NODE serializer writes that name straight into an &name; token. Direct XMLSerializer.serializeToString() output (including with requireWellFormed: true) can therefore close the entity-reference boundary and inject extra markup that a later parse treats as real XML structure. Confidentiality and availability are unaffected; document integrity is. The library parser does not create these nodes itself and rejects inserting them as element children, so the flaw is reachable only when application code creates an EntityReference and serializes that node or fragment.

Why it matters to the business

Services that take untrusted names, wrap them in entity references, and then serialize or reparse XML can have document structure silently changed—corrupting records, weakening XML-based checks, or feeding bad data to downstream processors. The issue is not in CISA KEV, has no known in-the-wild use, and is about a month old, so opportunistic mass exploitation is currently unlikely. Residual risk is highest where the unmaintained xmldom package (no patch) is still in the tree, or where EntityReference nodes are built from user or partner input.

How an attack unfolds

An attacker needs an application that passes attacker-influenced input to createEntityReference and then serializes that node or a containing fragment. They supply a name the library should reject but does not. Serialization emits the name inside an entity-reference token without keeping the token well-formed, so the resulting string contains extra markup. When that string is parsed again—by the same service, a peer, or a client—the injected markup becomes XML structure under the attacker’s control. No privileges or user interaction are required at the library layer, but the create-and-serialize path must be exposed. No public exploits, named threat actors, or ransomware campaigns are associated with this issue.

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 (or later). The unscoped xmldom package (0.6.0 and earlier) has no fixed release—migrate to @xmldom/xmldom at a patched version. Do not pass untrusted strings into Document.createEntityReference(); allowlist names against the XML Name production or stop creating EntityReference nodes. Refresh lockfiles and redeploy every service that bundles the library, including transitive dependents.

How to confirm the fix worked

Inventory SBOMs and lockfiles for xmldom and @xmldom/xmldom. Confirm resolved versions are 0.8.15+ or 0.9.12+ and that unscoped xmldom is gone. Search source for createEntityReference and XMLSerializer.serializeToString. After upgrade, regression-test serialize/parse round-trips, especially any EntityReference path, and confirm invalid names can no longer break entity-reference tokens under requireWellFormed serialization.

Typical attack path

1. Find an application that uses a vulnerable xmldom build and builds EntityReference nodes from external input
2. Submit an invalid entity name intended to break out of the serialized entity-reference token
3. Trigger XMLSerializer.serializeToString() on that node or a fragment that contains it
4. Cause the serialized string to be parsed again by the same or another XML processor
5. Use the injected structure to alter document content or bypass XML-driven business or schema checks

How to detect it

No public exploitation or named actors are reported. Hunt application and XML-processing logs for well-formedness failures, unexpected elements or attributes after a serialize/parse round-trip, and stack traces involving XMLSerializer.serializeToString or createEntityReference. Review dependency diffs and node_modules/lockfiles for vulnerable xmldom or @xmldom/xmldom versions as exposure signals, not proof of compromise. Network traffic is unlikely to carry a distinctive signature.

What your security team should do

• Upgrade @xmldom/xmldom to 0.8.15 or 0.9.12 in every XML-serializing service
• Replace unmaintained xmldom with patched @xmldom/xmldom; there is no fix for xmldom itself
• Locate createEntityReference call sites and restrict names to an allowlist or remove the API use
• Treat as a normal patch if you never create EntityReferences from untrusted input; treat as high priority if you do
• Add SCA policy blocking xmldom <= 0.6.0 and @xmldom/xmldom below 0.8.15 / 0.9.12