CVE-2026-128342 in ExcelJS
Summary
by MITRE • 11/13/2026
ExcelJS through 4.4.0 contains a denial of service vulnerability that allows attackers to block the event loop by supplying an unbounded sheetId in xl/workbook.xml. Attackers can provide a workbook with a huge sheetId, making the sparse worksheet array walk stall worksheets, getWorksheet and writeBuffer for seconds.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/13/2026
The ExcelJS library, widely used for parsing and generating Microsoft Excel files within Node.js environments, contains a critical denial of service vulnerability in versions through 4.4.0. This flaw stems from an unbounded sheet identifier handling mechanism located within the xl/workbook.xml processing logic. When the library parses an XML workbook definition file, it constructs internal data structures to map worksheet identifiers to their corresponding objects. The specific technical failure occurs because the implementation does not enforce strict limits on the size or format of the sheetId attribute provided by the input file. This lack of validation allows attackers to inject a maliciously crafted Excel file containing an excessively large or malformed sheet identifier, which triggers inefficient memory allocation and processing behaviors within the library's core parsing routines.
The operational impact of this vulnerability is severe in server-side applications that process user-uploaded Excel files without adequate sandboxing or input sanitization. By supplying a workbook with a huge sheetId, an attacker can cause the sparse worksheet array iteration to stall significantly. This stalls critical functions such as getWorksheet and writeBuffer for several seconds, effectively blocking the Node.js event loop. Since Node.js operates on a single-threaded event-driven architecture, this blockage prevents the application from handling any other concurrent requests or tasks during the duration of the attack. Consequently, legitimate users experience service degradation or complete unavailability, constituting a classic denial of service scenario that can be exploited remotely with minimal effort and resources.
From a classification perspective, this vulnerability aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, as the attacker forces the application to consume excessive processing time and potentially memory during the parsing phase. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is indicative of T1496, Resource Hijacking, where an adversary uses computing resources for their own purposes or disrupts availability by exhausting system capacity. The specific mechanism of blocking the event loop also relates to CWE-835, Loop with Unreachable Exit Condition, as the internal logic enters a state that prevents timely completion of operations due to the pathological input size.
To mitigate this risk, developers should immediately upgrade ExcelJS to version 4.4.1 or later, where these bounds checking mechanisms have been implemented and validated against malicious inputs. For applications unable to update the library immediately, it is crucial to implement strict file upload validation policies that reject any workbook files exceeding reasonable size limits for sheet identifiers before they are passed to the parsing engine. Additionally, running ExcelJS operations within a worker thread or a separate process can isolate the impact of such attacks, preventing them from blocking the main application event loop and ensuring continued availability for other services.