CVE-2026-54063: Excelize DoS via Malicious Row Attributes—Denial of Service Risk
Excelize, a popular Go library for handling Excel spreadsheets, contains a flaw in how it processes XML row definitions. When opening a malicious XLSX file, the library fails to validate the row count before allocating memory, allowing attackers to either exhaust system memory or crash the application. No login or user interaction is required—simply opening a crafted file triggers the problem. Services that process user-supplied Excel files are at risk.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-770
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-07-10 / 2026-07-16
NVD description (verbatim)
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. Prior to 2.11.0, the checkSheet() function in github.com/xuri/excelize/v2 uses an attacker-controlled <row r="N"> XML attribute value directly as the length argument to make([]xlsxRow, row) without validating it against the Excel row limit (TotalRows = 1,048,576). A specially crafted XLSX file can trigger two denial-of-service variants: (A) an out-of-memory process kill when r=2147483647 forces a ~16 GB allocation attempt, and (B) a runtime panic via out-of-bounds slice indexing when r=-1. Any service that opens attacker-supplied XLSX files and calls GetCellValue is affected. No authentication is required. This issue is fixed in version 2.11.0.
3 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The checkSheet() function in Excelize prior to 2.11.0 reads the row attribute (r) from XLSX XML markup without enforcing the Excel row limit of 1,048,576. The attacker-controlled value is passed directly to make([]xlsxRow, row), creating a slice with the specified capacity. When r=2147483647, this attempts to allocate approximately 16 GB of memory, causing out-of-memory termination. Alternatively, when r is set to a negative value such as -1, the runtime panics due to out-of-bounds slice indexing. The vulnerability is classified as CWE-770 (Allocation of Resources Without Limits or Throttling).
Business impact
Any application or service using Excelize to process user-supplied XLSX files faces availability risk. Affected services could experience sudden crashes, memory exhaustion, and service interruptions. This is particularly concerning for document processing platforms, data pipeline workers, reporting systems, and APIs that accept file uploads. Attackers can disrupt service without authentication, making this a reliable denial-of-service vector against public-facing or internal tools.
Affected systems
The vulnerability affects Excelize versions prior to 2.11.0. The impact is limited to applications that: (1) use the Excelize library, (2) process XLSX files from untrusted sources, and (3) call GetCellValue or related functions that trigger checkSheet(). Go-based applications and services integrating Excelize are the primary targets.
Exploitability
Exploitability is high and straightforward. An attacker need only craft an XLSX file with a malicious row attribute and send it to a vulnerable service. No authentication, user interaction, or special privileges are required. The attack succeeds immediately upon file processing. The CVSS score of 7.5 reflects the high likelihood of exploitation and significant availability impact, though confidentiality and integrity are unaffected.
Remediation
Upgrade Excelize to version 2.11.0 or later, which implements proper validation of the row attribute against Excel's row limits. Organizations unable to update immediately should implement input validation or sandboxing for XLSX file processing, restrict file uploads to trusted sources, and monitor services for unexpected memory spikes or crashes.
Patch guidance
Apply Excelize version 2.11.0 or newer. For Go projects using go.mod, update the dependency by running 'go get -u github.com/xuri/excelize/v2' and rebuild. Verify the update by checking your go.mod file shows v2.11.0 or later. Test the updated library against your application's file processing workflows before production deployment.
Detection guidance
Monitor for: (1) sudden out-of-memory errors or process terminations in applications using Excelize, especially following file uploads; (2) runtime panic messages referencing slice allocation failures; (3) unusual memory consumption spikes correlated with XLSX file processing; (4) HTTP 5xx errors or service unavailability following file submission. Log XLSX parsing errors and alert on repeated failures from the same source. Consider scanning uploaded XLSX files for unusually large row attributes as a preventive measure.
Why prioritize this
This vulnerability warrants urgent patching priority due to its ease of exploitation, lack of authentication requirements, and direct impact on service availability. Any organization operating file processing services should treat this as a critical update. The attack surface is broad—any publicly accessible XLSX upload endpoint becomes an immediate DoS vector.
Risk score, explained
The CVSS 7.5 HIGH score reflects a network-exploitable, low-complexity attack with no privileges or user interaction needed, resulting in complete availability loss (integrity and confidentiality are not impacted). The severity is driven by reliability of exploitation and the prevalence of Excel file handling in business applications. Organizations relying on Excelize-based services should treat this as a priority remediation item.
Frequently asked questions
Does this vulnerability allow data theft or modification?
No. The vulnerability causes denial-of-service through memory exhaustion or crashes only. Attackers cannot read, modify, or extract data from Excel files. Confidentiality and integrity are not compromised.
What versions of Excelize are vulnerable?
All versions prior to 2.11.0 are affected. Version 2.11.0 and later include the necessary validation fixes.
Can this be exploited against services that only read specific cells (GetCellValue)?
Yes. The vulnerability is triggered during the checkSheet() function, which runs during XLSX parsing before individual cell access occurs. Any application that opens and processes an XLSX file is vulnerable, regardless of which cell operations it performs.
Is there a workaround if we cannot patch immediately?
Consider implementing file validation: check that the row attribute in the XLSX XML does not exceed 1,048,576 before passing to Excelize, restrict XLSX uploads to trusted sources, run file processing in isolated containers with memory limits, and monitor for resource exhaustion. However, upgrading to 2.11.0+ is the recommended solution.
This analysis is based on the CVE-2026-54063 description and CVSS 3.1 assessment as of the publication date. Organizations should verify patch availability and compatibility with their specific Excelize versions and Go environments. This vulnerability does not appear on the CISA KEV catalog as of the analysis date; however, security teams should monitor for updates and treat it as a priority based on their file processing exposure. Always test patches in non-production environments before deployment. Source: NVD (public-domain), retrieved 2026-08-17. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2023-54365HIGHTraefik HTTP/2 Denial of Service Vulnerability – Rapid Reset Attack
- CVE-2025-46638HIGHDell BSAFE SSL-J Resource Exhaustion DoS Vulnerability
- CVE-2025-61028HIGHOpenLink Virtuoso DoS Vulnerability in time_t_to_dt Component
- CVE-2025-7737HIGHHitachi VSP iSCSI DoS Vulnerability – Patch Guide
- CVE-2026-11586HIGHcurl WebSocket Memory Exhaustion Denial-of-Service
- CVE-2026-11946HIGHopen62541 Memory Exhaustion via GetEndpoints Discovery Service
- CVE-2026-12151HIGHundici WebSocket Memory Exhaustion DoS Vulnerability
- CVE-2026-13698HIGHOpenVPN Memory Leak Denial of Service Vulnerability