CVE-2026-54063 in excelize
Summary
by MITRE • 07/10/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in Excelize library represents a critical security flaw that enables remote denial-of-service attacks through manipulation of XML attribute values in Microsoft Excel spreadsheet files. This issue affects versions prior to 2.11.0 and stems from insufficient input validation within the checkSheet() function located in github.com/xuri/excelize/v2. The root cause lies in the direct utilization of attacker-controlled XML attribute values as parameters for memory allocation operations without proper bounds checking against Excel's inherent row limitations.
The technical exploitation occurs when an attacker crafts a malicious XLSX file containing specially formatted XML attributes that bypass normal validation mechanisms. When the vulnerable library processes such files through functions like GetCellValue, the checkSheet() function interprets these unvalidated values as direct length parameters for slice allocation operations. This creates two distinct attack vectors that demonstrate different aspects of the same underlying flaw. The first variant involves setting a row count value of 2147483647 which triggers an attempted memory allocation of approximately 16 gigabytes, overwhelming system resources and causing process termination due to out-of-memory conditions. The second variant uses a negative value of -1 which results in runtime panic through out-of-bounds slice indexing operations that violate Go's memory safety mechanisms.
This vulnerability operates at the intersection of XML parsing security and memory management errors, fundamentally compromising system stability and availability. The attack surface extends to any service or application that processes untrusted XLSX files through the affected library version, including web applications, file processing services, and automated data ingestion systems. The lack of authentication requirements makes this particularly dangerous as any remote attacker can trigger these conditions without requiring user credentials or privileged access. The impact spans both immediate system availability issues and potential cascading failures in larger distributed systems where such processing occurs.
From a cybersecurity perspective, this vulnerability aligns with CWE-129 and CWE-704 classifications that address improper input validation and insufficient boundary checking respectively. The attack pattern follows common threat models documented in MITRE ATT&CK framework under T1499 which covers network denial of service attacks. Organizations utilizing Excelize library versions prior to 2.11.0 face significant risk exposure, particularly those handling untrusted file uploads or automated spreadsheet processing workflows. The fix implemented in version 2.11.0 addresses the core validation issue by introducing proper bounds checking against Excel's maximum row limit of 1,048,576 rows, ensuring that all input values are validated before being used in memory allocation operations.
Mitigation strategies should prioritize immediate upgrade to version 2.11.0 or later releases of the Excelize library while implementing additional defensive measures such as file format validation, resource monitoring, and process isolation for spreadsheet processing components. Organizations should also consider implementing sandboxed environments for untrusted file processing and establishing automated vulnerability scanning processes to identify similar issues in other third-party libraries. The vulnerability demonstrates the critical importance of input validation in security-critical code paths and underscores the necessity of comprehensive security testing for libraries handling structured data formats like XML-based spreadsheet files.