CVE-2026-83614
Summary
by MITRE • 09/01/2026
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module. Prior to @xmldom/xmldom versions 0.8.15 and 0.9.12, and in xmldom versions 0.3.0 through 0.6.0, two independent quadratic paths can cause denial of service. In lib/sax.js, parseElementStartPart repeatedly rescans a malformed tag name to the next > during single-character recovery; in lib/dom.js, normalize() repeatedly removes and appends adjacent text nodes, causing quadratic reindexing and string rebuilding. The first path is reachable through default DOMParser.parseFromString() processing, while the second is also reachable through a direct normalize() call on a programmatically constructed DOM, and endDocument invokes that normalization after parsing. This issue is fixed in @xmldom/xmldom versions 0.8.15 and 0.9.12; no fixed version is available for xmldom.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified involves the JavaScript library xmldom, which implements a W3C standard-based DOMParser and XMLSerializer module. This package has been widely used in Node.js environments to parse and manipulate XML documents programmatically. The core issue lies within two distinct code paths that exhibit quadratic time complexity relative to input size, leading to potential denial of service conditions. These flaws were present in xmldom versions ranging from 0.3.0 through 0.6.0, as well as in specific earlier releases of the maintained fork @xmldom/xmldom prior to versions 0.8.15 and 0.9.12. The existence of these vulnerabilities highlights critical performance regressions that can be exploited by attackers providing maliciously crafted XML inputs or constructing complex DOM structures programmatically.
The first vulnerability path resides in the lib/sax.js file, specifically within the parseElementStartPart function. When processing a malformed tag name, this function employs single-character recovery logic that repeatedly rescans the input string to locate the next greater-than symbol. This approach results in quadratic behavior because for every character scanned during recovery, previous characters may be re-examined multiple times depending on the structure of the malicious payload. An attacker can craft an XML document with a specifically designed malformed tag name that triggers this repeated scanning process extensively. As the size of the input increases, the processing time grows exponentially rather than linearly, causing significant CPU consumption and eventual unresponsiveness in the application hosting the parser. This specific flaw is reachable through standard usage patterns where developers utilize the default DOMParser.parseFromString method to parse external or user-supplied XML data without sufficient validation or length limits.
The second vulnerability path is located in lib/dom.js within the normalize function, which is responsible for merging adjacent text nodes and removing empty ones according to W3C DOM specifications. The implementation flaw causes this function to repeatedly remove and append adjacent text nodes during normalization, leading to quadratic reindexing of node lists and repeated string rebuilding operations. This behavior becomes particularly severe when dealing with large numbers of small text nodes or deeply nested structures that require extensive normalization. Unlike the first path which is triggered by parsing malformed XML, this second vector can be exploited both through direct invocation of normalize() on a programmatically constructed DOM tree and indirectly via endDocument processing after parsing operations. This dual accessibility means that even applications not directly parsing untrusted XML but rather building DOM structures from trusted sources could potentially trigger the vulnerability if they perform normalization on large or complex node sets without proper safeguards.
The operational impact of these vulnerabilities is primarily denial of service through resource exhaustion. Since JavaScript engines typically run single-threaded, a quadratic complexity attack can effectively freeze the event loop for extended periods, preventing the application from handling other requests or performing critical tasks. In server-side applications using Node.js, this can lead to complete unavailability of services as worker threads become blocked processing malicious inputs. The lack of fixed versions for older xmldom releases further exacerbates the risk for legacy systems that cannot easily upgrade dependencies due to compatibility constraints with surrounding codebases. Organizations relying on these outdated versions remain exposed indefinitely unless they implement workarounds or migrate to secure alternatives.
Mitigation strategies should prioritize upgrading to patched versions where available, specifically @xmldom/xmldom 0.8.15 or later and version 0.9.12 or later for the maintained fork. For systems constrained to older xmldom releases between 0.3.0 and 0.6.0 that cannot be upgraded due to legacy dependencies, developers must implement strict input validation and size limits on XML documents before parsing. Additionally, avoiding direct calls to normalize() on large DOM trees or limiting the depth and breadth of programmatically constructed nodes can reduce exposure to the second vulnerability path. Implementing timeout mechanisms for long-running JavaScript operations may also help mitigate the impact by terminating processes that exceed expected execution times due to quadratic behavior.
From a classification perspective, these vulnerabilities align with CWE-400 Uncontrolled Resource Consumption, as they allow attackers to exhaust computational resources through inefficient algorithmic complexity rather than memory leaks or buffer overflows. The exploitation vectors correspond to ATT&CK technique T1496 Resource Hijacking, where adversaries leverage system resource consumption to degrade service availability. Understanding these mappings helps security teams prioritize remediation efforts based on established industry standards and threat intelligence frameworks. Regular auditing of dependency versions and implementing automated scanning for known quadratic complexity patterns in XML processing libraries can prevent similar issues from impacting production environments in the future.