The vulnerability is a Denial-of-Service in the excelize library caused by unbounded resource allocation when parsing a crafted XLSX file. The root cause is the lack of validation on the <row r="N"> attribute in the worksheet's XML data. An attacker can set the row number N to a very large positive integer or a negative integer.
When a function like GetCellValue is called, it triggers a call chain that leads to the (*xlsxWorksheet).checkSheet function. In its vulnerable state, this function uses the attacker-controlled row number to allocate a slice of xlsxRow structs without checking if the number is within the valid range for Excel worksheets (1 to 1,048,576).
- A large positive value (e.g.,
2147483647) causes an attempt to allocate a massive amount of memory (~16GB), leading to an out-of-memory (OOM) error that terminates the process.
- A negative value (e.g.,
-1) bypasses the initial allocation loop and then causes a panic due to an out-of-bounds slice access (sheetData.Row[-2]).
The analysis of the commits between the vulnerable version (2.10.1) and the patched version (2.11.0) revealed the exact fix. Commit 875b959ba62fc9bf45bb0de547ae7c7f7549835c introduces boundary checks in the checkSheet function by adding a new checkRowNum helper function. This directly remediates the vulnerability described.
The provided stack trace confirms the call chain during exploitation: GetCellValue -> getCellStringFunc -> workSheetReader -> checkSheet. All these functions would appear in a runtime profile.
Additionally, a similar vulnerability was patched in the (*Rows).Next method (used by GetRows) in commit 93f0b3caed37f21ef5079e3259c6c21dcfe68453, indicating another vector for the same type of attack. Therefore, functions from both exploitation paths are included in the analysis.