CVE-2026-78206 in exceljs-hardened
Summary
by MITRE • 08/24/2026
exceljs-hardened before 5.0.0 decompresses all entries from supplied xlsx archives into memory without limits on entry size, total size, or compression ratio. Attackers can upload highly compressed workbooks that expand to gigabytes in memory, exhausting available resources and causing denial of service.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in exceljs-hardened versions prior to 5.0.0 represents a critical resource exhaustion flaw rooted in the library's handling of archive decompression operations. Specifically, the software processes Excel files by extracting all contained entries into system memory without implementing any constraints on individual entry sizes, cumulative total size, or compression ratios. This architectural decision assumes that input data will be reasonably sized and uncompressed to manageable levels, which is a dangerous assumption in environments where user-supplied content is processed automatically. By failing to validate the potential expansion factor of compressed streams before allocation, the application becomes susceptible to resource manipulation attacks where malicious actors can craft inputs designed to trigger disproportionate memory consumption relative to their file size on disk.
From an operational perspective, this flaw enables a straightforward denial of service attack vector. An attacker can upload or submit an xlsx archive that is small in physical size but utilizes compression algorithms and structures specifically engineered to expand into gigabytes of data when decompressed. As the library attempts to load these entries into memory, it rapidly consumes available heap space on the server hosting the application. This uncontrolled allocation leads to out-of-memory conditions, causing the process to crash or become unresponsive. In a web service context, this results in the inability to serve legitimate requests, effectively taking down the associated functionality until the system is restarted or resources are manually reclaimed. The impact extends beyond simple downtime; it can also lead to cascading failures if multiple such requests are processed concurrently, potentially exhausting memory across an entire cluster of application servers.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-400, which describes Uncontrolled Resource Consumption. It is a specific instance where the lack of limits on resource usage allows for denial of service through memory exhaustion. Furthermore, this flaw can be mapped to MITRE ATT&CK technique T1496, Resource Hijacking, specifically under the sub-technique of Denial of Service via resource consumption. The attack relies on exploiting the application's trust in input data integrity and size expectations, bypassing any implicit or explicit safeguards against maliciously crafted archives.
To mitigate this vulnerability, organizations must upgrade to exceljs-hardened version 5.0.0 or later, where these limits have been implemented. For environments unable to immediately patch, defensive measures should include implementing strict file upload policies that limit the maximum size of accepted xlsx files at the network or application gateway level before they reach the processing library. Additionally, introducing a pre-processing step that validates and potentially sanitizes archive contents can help detect anomalously high compression ratios indicative of zip bombs. Monitoring system memory usage for sudden spikes correlated with file uploads can also aid in early detection of such attacks, allowing for automated blocking or alerting mechanisms to be triggered before critical resource exhaustion occurs.