GHSA-8mcq-6wmr-jrjv: Medium severity go/github.com/xuri/excelize/v2 vulnerability
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.
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
Event History
Frequently Asked Questions
Which application workflows are exposed?
Any service that opens an untrusted spreadsheet and uses non-streaming worksheet APIs that reach workSheetReader and checkRow is exposed. This includes GetCellValue, GetCellFormula, CalcCellValue, GetMergeCells, SetCellValue, and essentially every other non-streaming worksheet operation.
What does an attacker need to provide?
The attacker needs a spreadsheet containing a row where a cell appearing earlier in XML document order references a higher column than the row's final cell. No authentication is required, but a user or service must open the attacker-controlled spreadsheet and invoke an affected worksheet API.
Can streaming worksheet processing avoid the vulnerable path?
Yes. The streaming GetRows and Rows() SAX path does not invoke the vulnerable checkRow processing described here. Using those APIs can avoid this specific trigger while patching is unavailable.
How can I identify spreadsheets that trigger the condition?
Inspect worksheet row XML for cells that are not ordered by column reference. A row is dangerous when an earlier cell has a column number greater than the column number of the last cell in document order.