CVE-2026-107221: Excelize: a row whose earlier cell has a higher column reference than its last cell panics index out of range on almost every worksheet read API
Affected versions and vulnerable location
- Confirmed at ae2113b (current HEAD). - Sink: rows.go:967 ws.SheetData.Row[rowIdx].C[colNum-1] = colData inside checkRow. - checkRow computes lastCol from the column of the last cell in document order (rows.go:940), allocates targetList of that length, then re-scatters every source cell into C[colNum-1].
Root cause
The slice is sized from the last cell's column, but cells are not required to be column-sorted in the XML. A cell that appears earlier in the row but references a higher column than the last cell has colNum-1 >= len(targetList), so the assignment writes out of range. MaxColumns/TotalRows do not help, every individual column is valid; the bug is the ordering assumption, not magnitude.
Attacker model and reachability
Any service that opens an untrusted spreadsheet and calls a worksheet API that goes through workSheetReader -> checkRow (excelize.go:332): GetCellValue, GetCellFormula, CalcCellValue, GetMergeCells, SetCellValue, and essentially every non-streaming worksheet call. (The streaming GetRows/Rows() SAX path does not trigger it.) Unauthenticated, deterministic, unrecovered panic -> process crash.
Proof of concept (executed)
Crafted xl/worksheets/sheet1.xml with a row whose cells are out of column order and whose earlier cell exceeds the last cell's column:
xml <row r="1"><c r="D1"><v>4</v></c><c r="C1"><v>3</v></c></row>
GetCellValue("Sheet1","A1") (via getCellStringFunc -> workSheetReader -> checkRow) panicked index out of range [3] with length 3 at rows.go:967.
Confirming grep:
bash rg -n "func checkRow|lastCol|Row\[rowIdx\].C\[colNum-1\]" rows.go
Suggested fix
Size targetList from the maximum cell column in the row (not the last cell in document order), or bounds-check colNum-1 against len(targetList) and grow the slice as needed before the assignment.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/xuri/excelize/v2to a version that resolves this vulnerability.Fixed in 2.11.1-0.20260816084418-46a5eb289448 - Compensating control
Fix checkRow so targetList is sized from the maximum cell column in the row rather than the last cell in XML document order, or bounds-check colNum-1 against len(targetList) and grow the slice before assigning to Row[rowIdx].C[colNum-1].
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using Excelize versions 2.0.0 through 2.11.0 are exposed when they read attacker-controlled or otherwise malformed Excel worksheets through a non-streaming worksheet API. The impact is process termination from an unrecovered panic.
What must an attacker provide to trigger the panic?
The attacker needs a crafted worksheet row in which a cell with a higher column reference appears earlier in XML document order than the row's final, lower-column cell. A user or application must then cause a non-streaming worksheet read API to read that sheet.
Is a fix available?
No fixed version was available as of the review. The affected range is reported as Excelize 2.0.0 through 2.11.0.
What can be done while no patch is available?
Avoid processing untrusted Excel files with affected non-streaming worksheet APIs where possible. Treat spreadsheet ingestion as a process-availability risk, since a crafted file can terminate the application process.