CVE-2026-83611

What it actually does

A JavaScript W3C-style XML parser (xmldom / @xmldom/xmldom) silently accepts certain malformed end tags that contain a newline and trailing residue, closes the element, and discards the extra content instead of failing well-formedness. On 0.9.x the SAX end-tag check inherits a multiline regex flag so only the first line must match the XML ETag production; older 0.8.x and unscoped 0.6.x lines lack equivalent residue validation. The result is a parser differential against strict XML processors: untrusted input can pass a parse-before-trust gate. Discarded bytes are not injected into the DOM. Direct impact is limited integrity of the parsed tree (CVSS VI:L); confidentiality and availability are unaffected.

Why it matters to the business

Any product that treats a successful parse as proof that XML is well-formed and therefore safe may accept documents it intended to reject, causing incorrect processing, authorization or policy bypass, or inconsistent behavior versus other XML stacks. This is an integrity problem, not data theft or downtime. The flaw is not in CISA KEV, has no known in-the-wild or ransomware use, and exploit maturity is None about a month after publication, so urgency comes from how commonly this library sits on XML trust boundaries in Node.js and bundled front-end code rather than from active campaigns. Unscoped xmldom has no patch, so remaining on that package leaves a permanent gap.

How an attack unfolds

An unauthenticated attacker sends XML or XML-like content to an application that parses it with a vulnerable DOMParser.parseFromString() and then trusts parse success as a well-formedness control. The input uses an end tag that looks valid on the first line while a newline and extra characters follow. The vulnerable parser closes the element and drops the residue without the hard failure a strict processor would raise (onError on 0.9.x, errorHandler on 0.8.x). Downstream logic then runs on a document that should have been rejected. Discarded content is not inserted into the tree, so this is a trust-boundary bypass rather than XXE or entity injection. No named APT groups or ransomware campaigns are associated with this issue.

How to fix it

Upgrade @xmldom/xmldom to 0.8.15 on the 0.8.x line or 0.9.12 on the 0.9.x line. Unscoped xmldom 0.6.0 and earlier has no fixed release; migrate to scoped @xmldom/xmldom at a patched version. Configure onError (0.9.x) or errorHandler (0.8.x) to fail closed on parse errors. Do not treat parse success as the only well-formedness control; combine parsing with schema validation and deny-by-default error handling. Rebuild and redeploy every artifact that bundles the library (services, front-end bundles, functions, container images).

How to confirm the fix worked

Search lockfiles and node_modules for @xmldom/xmldom below 0.8.15 or 0.9.12 and for unscoped xmldom 0.6.0 or earlier; confirm resolution with a package-tree listing. After upgrade, submit documents that are not well-formed, including end tags with unexpected trailing characters after a newline, and verify the parser rejects them via onError or errorHandler rather than silently closing elements. Regression-test any parse-before-trust or well-formedness gates and confirm transitive copies in bundles were refreshed.

Typical attack path

1. Locate an application path that parses untrusted XML with vulnerable xmldom or @xmldom/xmldom and uses a successful parse as a well-formedness or trust gate.
2. Submit XML whose end tags include a line break and trailing characters that a strict XML processor would reject.
3. Vulnerable parseFromString() accepts the document, closes the element, and discards residue without failing closed.
4. Downstream business logic, transformation, or authorization proceeds as if the XML were well-formed.
5. Attacker obtains a limited integrity effect (validation or policy bypass) without injecting discarded content or causing confidentiality or availability impact.

How to detect it

No public exploit, KEV listing, or named threat-actor activity is reported, so hunt for exposure and anomalous parse outcomes rather than campaign malware. Inventory lockfiles and runtime trees for vulnerable package versions. Review XML-ingestion application logs for input that other XML stacks rejected but xmldom accepted without onError or errorHandler failures. Compare rejected versus accepted documents around trust gates. Network bodies with end tags split across lines are only meaningful in a parse-before-trust workflow; discarded residue is not written into the DOM, so distinct host artifacts from this bug alone are unlikely.

What your security team should do

• Inventory direct and transitive use of xmldom and @xmldom/xmldom in services, front-end bundles, and serverless artifacts.
• Upgrade @xmldom/xmldom to 0.8.15 or 0.9.12; replace unscoped xmldom <= 0.6.0 with the scoped patched package.
• Fail closed on parser errors and stop using parse success as the sole well-formedness control.
• Prioritize internet-facing XML ingestion (APIs, document upload, SAML/SOAP, feeds) over internal tooling.
• Add SCA or policy gates that block vulnerable versions.
• No KEV due date applies; schedule as a standard integrity-impact library patch given exploit maturity of None.