---
id: "CVE-2026-128343"
page: "https://infrastack.ai/live/CVE-2026-128343"
kind: "vulnerability"
aliases: ["CVE-2026-128343"]
title: "exceljs through 4.4.0: XLSX with a huge row number blocks the Node event loop (fix only in exceljs-hardened 5.1.0)"
severity: "high"
cvss: 8.7
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "exceljs", "fixed": [], "affected": "<= 4.4.0", "ecosystem": "npm"}, {"name": "exceljs-hardened", "fixed": ["5.1.0"], "affected": "<= 5.0.2", "ecosystem": "npm"}]
ecosystems: []
tags: ["exceljs", "exceljs-hardened", "node", "npm", "package", "xlsx-upload"]
not_affected_if: ["no-xlsx-parsing", "trusted-input-only"]
published_at: "2026-11-13T10:18:14+00:00"
first_seen_at: "2026-11-13T10:47:34+00:00"
updated_at: "2026-11-13T10:50:02+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-128343", "first_seen_at": "2026-11-13T10:47:34+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-13T10:50:02+00:00"}]
exploit_sources: []
---

# exceljs through 4.4.0: XLSX with a huge row number blocks the Node event loop (fix only in exceljs-hardened 5.1.0)

Link for people: https://infrastack.ai/live/CVE-2026-128343 (this .md is for agents)

exceljs through 4.4.0 parses the row attribute of XLSX files without a bound, so a row numbered far beyond Excel's limit is accepted. Processing such a file makes getSheetValues(), workbook writes and CSV export consume time proportional to that number, blocking the event loop.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:exceljs affected <= 4.4.0 fixed no fixed version listed
- npm:exceljs-hardened affected <= 5.0.2 fixed 5.1.0

## How to check

Run `npm ls exceljs exceljs-hardened`. exceljs <= 4.4.0 is affected, with no upstream fix found. exceljs-hardened <= 5.0.2 is affected, and 5.1.0 is fixed. Then look for code that reads untrusted XLSX through exceljs (wb.xlsx.load/readFile, getSheetValues, xlsx.writeBuffer, csv.writeBuffer). A test file puts <row r="20000000"> in xl/worksheets/sheet1.xml. The advisory reports about 0.6 s for getSheetValues, 1.2 s for an xlsx write and 6.2 s for CSV at that row number, growing linearly.

## Fix

exceljs-hardened: upgrade to 5.1.0 (maintainer advisory). Upstream exceljs: no patched release found; 4.4.0 is the latest on its releases page. Until then, reject or cap row numbers (Excel's maximum is 1,048,576) before parsing untrusted XLSX, or run parsing in a worker or separate process with a timeout. Or switch to exceljs-hardened 5.1.0.

## Timeline

- 2026-11-13T10:47:34+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-128343
- 2026-11-13T10:50:02+00:00 analyst — GHSA-3gm5-qxj8-89rr is published on the exceljs-hardened fork (<=5.0.2, patched 5.1.0). It is not an upstream exceljs advisory. The upstream releases page lists 4.4.0 as the latest release and no fix. PoC with timings is in the advisory.

## Documents

- [advisory] Vendor advisory: github.com https://github.com/mateocallec/exceljs-hardened/security/advisories/GHSA-3gm5-qxj8-89rr
- [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/exceljs-through-4.4.0-denial-of-service-via-oversized-row-number

## From the sources

exceljs through 4.4.0 contains a denial of service vulnerability that allows attackers to block the event loop by supplying unbounded row r attributes parsed in row-xform.js. Attackers can craft an XLSX file with a row numbered far beyond Excel's limit, making getSheetValues(), workbook writes and CSV export consume time proportional to that number.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_