CVE-2026-107221 in Excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.0.0 to 2.11.0, checkRow sizes its target cell slice from the last cell in XML document order and then re-scatters every cell by its explicit column reference. GetCellValue reaches workSheetReader and checkRow, where targetList is too short for an earlier out-of-order cell. When a crafted row places a higher-column cell before a lower-column final cell and a non-streaming worksheet API reads the sheet, the earlier cell's column index exceeds the slice length derived from the final cell, allowing an attacker to cause an unrecovered panic and terminate the process. No fixed version is available as of this review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Excelize versions 2.0.0 through 2.11.0 represents a critical flaw within the Go language library used for processing Microsoft Excel spreadsheet files. This issue specifically affects the non-streaming worksheet API, which is designed to read and write data from XLSX documents by parsing their underlying XML structure. The core of the problem lies in how the library handles cell indexing during the reading process. When a workbook is loaded into memory using these specific APIs, Excelize attempts to organize cells based on their row and column coordinates to facilitate efficient access and manipulation. However, the internal logic for determining the size of the target cell slice relies on an assumption about the order in which cells appear within the XML document structure rather than strictly adhering to explicit coordinate data provided by each individual cell entry.
The technical flaw originates in the checkRow function, which is responsible for preparing the data structures that hold row information before values are extracted or modified. In vulnerable versions of the library, this function determines the required length of the target slice based on the last cell encountered when iterating through the XML document in its natural order. This approach assumes that cells appear sequentially by column index within each row. Consequently, if a crafted Excel file contains rows where higher-column-indexed cells are defined before lower-column-indexed final cells, the calculated slice size will be insufficient to accommodate all existing entries. The library fails to re-scatter or resize the array based on explicit maximum column references found across the entire row definition, leading directly to an index out of bounds condition when subsequent operations attempt to access data at indices that exceed the prematurely sized slice limits.
This architectural oversight results in a severe operational impact characterized by an unrecovered panic that terminates the application process immediately upon processing the malformed input. From a security perspective, this constitutes a Denial of Service vulnerability because it allows any user or automated system capable of uploading or providing access to such crafted Excel files to crash services relying on Excelize for document parsing. This is particularly dangerous in server-side applications where spreadsheet uploads are common features, as repeated exploitation can lead to significant service disruption and resource exhaustion due to frequent process restarts. The attack vector does not require authentication if the application processes uploaded files automatically or exposes endpoints that accept file inputs without rigorous validation of internal structure integrity prior to parsing.
From a classification standpoint, this vulnerability aligns with CWE-125, which describes Out-of-bounds Read scenarios where software reads data past the end or before the beginning of the intended buffer. Although the immediate result is a panic rather than arbitrary code execution via memory corruption in typical Go environments due to its garbage collection and bounds checking mechanisms, the underlying mechanism remains an invalid memory access attempt that disrupts normal program flow. In terms of adversarial tactics, this aligns with ATT&CK technique T1499, Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion or application crashes via malformed inputs. Attackers can leverage this flaw to destabilize infrastructure components such as web servers, data processing pipelines, or reporting tools that integrate Excelize for handling legacy spreadsheet formats.
Mitigation strategies must focus on input validation and defensive programming practices since no fixed version of the library is currently available according to the review period. Developers should implement strict schema validation against XLSX specifications before passing documents to Excelize parsers, ensuring that cell references are consistent with expected structural norms. Additionally, wrapping parsing operations in panic recovery mechanisms can prevent immediate process termination, allowing for graceful error handling and logging instead of abrupt crashes. Upgrading to a patched version as soon as it is released by the maintainers remains the primary long-term solution. Until then, restricting file upload capabilities or sandboxing the execution environment where Excelize operates can reduce the blast radius of potential exploitation attempts targeting this specific index calculation flaw.