HomeSecurityXLSX Security: exceljs-hardened 5.0.0 fixes 4 vulnerabilities

XLSX Security: exceljs-hardened 5.0.0 fixes 4 vulnerabilities

exceljs aNode.js library for reading and creating spreadsheets, is at the center of a new advisory. Exceljs-hardened 5.0.0 is recommended as a patched alternative for more secure XLSX. Exceljs-hardened 5.0.0 is recommended as a patched alternative for more secure XLSX. Four vulnerabilities affect version 4.4.0 and can lead to everything from local file disclosure to a service crash that processes XLSX files.

XLSX security with exceljs-hardened 5.0.0

The vulnerabilities were discovered on August 23 and were documented the next day in the NVD database. The team behind exceljs-hardened, an independent fork with security fixes, recommends version 5.0.0, as the official exceljs project has not yet incorporated these changes. The SecNews technical team notes that XLSX security is environment-dependent and that the risk mainly concerns applications that accept files or paths from untrusted users.

See also: RedC2 packages on npm install backdoor on Linux

What do exceljs vulnerabilities include?

The most immediate threat concerns the Workbook.addImage(). When the application passes an unchecked filename parameter, the library can read files that are accessible to the Node.js process. With appropriate path segments, a remote user can exploit path traversal and embed the content in an XLSX file returned by the service. The related advisory on GitHub gives the vulnerability a CVSS score of 10.0.

The second serious category is malicious file decompression. CVE-2026-78206 describes a small, highly compressed XLSX that can swell to gigabytes in memory, with no per-entry limit, total limit, or compression ratio check. The service can then run out of memory and terminate, causing a denial of service even with a single file upload.

Malicious XLSX files and memory exhaustion

Also included in the same set are CSV/formula injection, when values ​​starting with =, +, – or @ are written without escaping, and prototype pollution via annotation objects. The exceljs-hardened lists all four fixes so administrators can check if they are using the vulnerable functions.

The entries are particularly important because the library is used as an intermediary mechanism in upload services and reporting automation. There is no official fix in the upstream package yet, so simply updating the lockfile may not change the version. Checking the actual dependency and the permissions of the process executing it is required.

The entries are particularly important because the library is used as an intermediary mechanism in upload services and reporting automation. There is no official fix in the upstream package yet, so simply updating the lockfile may not change the version. Checking the actual dependency and the permissions of the process executing it is required.

XLSX security with exceljs-hardened 5.0.0

The fork is not an official continuation of exceljs nor is it affiliated with the original maintainers. It starts with version 4.4.0 and maintains a different package name, so as not to implicitly replace the upstream. Version 5.0.0 adds safe path checking for images, rejects paths with .. parts, and protects CSV exports with a quote character before a possible type.

For decompression, exceljs-hardened 5.0.0 checks the declared uncompressed size in the main directory of the file before reading the data. The default limits are 128 MB for a single entry and 512 MB for the entire file, and can be adjusted depending on the environment. Applications should consider any XLSX file as untrusted input, even if it comes from an internal user.

See also: Isolated-vm vulnerability with sandbox impact fixed

Path traversal in exceljs and reading files

What should administrators do?

Those using the official exceljs 4.4.0 should identify if the application calls the load, readFile, addImage or CSV.write functions with user-controlled data. The immediate option is to migrate to exceljs-hardened 5.0.0, after compatibility checking and testing in a simulation environment. Where package switching is not possible, strict path validation, file size limitation and process isolation are needed.

At the same time, development teams should avoid using CSV data directly in spreadsheet applications, disable unnecessary features, and monitor memory consumption and unusual failures. The SecNews editorial team recommends checking the lockfile, searching for all indirect dependencies, and recording the version used in each service.

Protecting Node.js from exceljs vulnerabilities

See also: Malicious package version infects Rust projects during compilation

Selecting the team

🔒 Protect your privacy with Proton VPN

Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.

  • ✔ No-logs, based in Switzerland (except 14-Eyes)
  • ✔ NetShield: blocks ads, trackers & malicious domains
  • ✔ Covers all devices — free version available
Try Proton VPN for free — 30-day money-back guarantee →

The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.

XLSX security does not mean that every application is automatically vulnerable. The actual impact depends on whether it accepts untrusted files and the permissions of the process. However, the exceljs vulnerabilities show why input validation, resource limits, and regular dependency reviews should be a permanent part of secure development.

📧
Subscribe to the SecNews Newsletter

The most important Security & Technology news in your Inbox.

Digital Fortress
Digital Fortresshttps://www.secnews.gr/politiki-syntaxis/
Member of the SecNews Editorial Team. Covers software vulnerabilities, data breaches, cyberattacks and technology developments. All articles follow the SecNews Editorial Policy.

SEARCH

FOLLOW US

📧
Newsletter SecNews
The most important Security & Technology news in your inbox.

LIVE NEWS