EUVD-2026-64681
GHSA-r7gv-hxj8-94c4
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered upload with no authentication or complexity barriers; scope unchanged; impact is availability-only with no confidentiality or integrity exposure.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Unbounded xlsx decompression in exceljs-hardened before 5.0.0 allows unauthenticated remote attackers to exhaust server memory and cause denial of service by uploading a crafted zip-bomb workbook. The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) reflects that exploitation requires no authentication, no special configuration, and no victim interaction beyond the server automatically parsing the uploaded file. No active exploitation has been confirmed (no CISA KEV listing) and no public exploit has been identified at time of analysis, but the zip-bomb technique targeting archive parsers is well-documented and requires minimal attacker skill.
Technical ContextAI
xlsx workbooks are ZIP archives, and the exceljs parser (CPE: cpe:2.3:a:exceljs:exceljs:*:*:*:*:*:*:*:*) reads all compressed entries into memory during workbook processing. CWE-409 (Improper Handling of Highly Compressed Data) describes this class of flaw: an attacker crafts an archive with an extreme compression ratio where a small on-disk payload expands to gigabytes in memory. The vulnerable code path is visible in the upstream exceljs repository at xlsx.js lines 257-281, which decompresses entries without enforcing any limit on individual entry size, total uncompressed size, or compression ratio. exceljs-hardened, a security-focused fork of exceljs, inherited this unbounded decompression behavior in all versions prior to 5.0.0.
RemediationAI
Upgrade exceljs-hardened to version 5.0.0 or later, which introduces enforcement of limits on per-entry decompressed size, total uncompressed size, and compression ratio. Full details are in the maintainer advisory at https://github.com/mateocallec/exceljs-hardened/security/advisories/GHSA-7cvf-3r55-r39q. If immediate upgrade is not feasible, apply compensating controls at the application or infrastructure layer: enforce a strict maximum file size on xlsx uploads before passing them to the parser (rejecting files above a reasonable threshold such as 10 MB prevents delivery of maximally compressed payloads, with no impact on legitimate workbooks within typical size bounds). Additionally, run xlsx parsing in an isolated process or container subject to an OS-level memory cap (e.g., via cgroup memory limits) so that a single malicious upload cannot exhaust host RAM. Note that file size limits alone do not fully eliminate risk if an attacker can craft a maximally compressed payload within the allowed limit; process isolation provides defense-in-depth.
An unescaped payload in exceljs <v1.6 allows a possible XSS via cell value when worksheet is displayed in browser. Rated
Prototype pollution in exceljs-hardened before 5.0.0 lets a remote attacker corrupt Object.prototype by feeding parsed J
Path traversal in exceljs-hardened before 5.0.0 allows unauthenticated attackers to read arbitrary files from the server
CSV formula injection in exceljs-hardened before version 5.0.0 allows attackers who can influence exported cell values t
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today