GITHUB.COM/XURI/EXCELIZE/V2 · CVE-2026-107220 · Package
FIX → 2.11.1-0.20260820023833-99903a3240e5
Excelize, a Go library for reading and writing Excel files, panics in cellInRange when a worksheet contains a mergeCell with an empty ref. A panic crashes the process that is handling the file, which can cause denial of service.
first public Aug 20, 2026 · 3 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Applications that use Excelize to open or parse untrusted or user-supplied .xlsx files are exposed, since a malformed worksheet can trigger the panic. Programs that only generate spreadsheets from trusted data, or never parse external files, are unlikely to be reached.
Not affected if no-xlsx-parsing, trusted-input-only
Who cares cwe-125, cwe-129, excelize, go, spreadsheet-parsing
github.com/xuri/excelize/v2 appears in go.mod and at what version.go list -m github.com/xuri/excelize/v2 in the project to see the resolved version.Upgrade to 2.11.1-0.20260820023833-99903a3240e5
A worksheet containing <mergeCell ref=""/> makes mergeCellsParser leave the cached rectangle empty, and cellInRange then indexes that empty slice without a length check. Every non-streaming cell API panics with index out of range [0] with length 0 on the first cell read after opening the file.
cell.go, cellInRange
func cellInRange(cell, ref []int) bool {
return cell[0] >= ref[0] && cell[0] <= ref[2] && cell[1] >= ref[1] && cell[1] <= ref[3]
}
ref is indexed at four positions with no bounds check.
The caller that can hand it an empty slice,
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
github.com/xuri/excelize/v2 to 2.11.1-0.20260820023833-99903a3240e5 or later.mergeCellsParserif ref := ws.MergeCells.Cells[i].Ref; len(ws.MergeCells.Cells[i].rect) == 0 && ref != "" {
if strings.Count(ref, ":") != 1 {
ref += ":" + ref
}
rect, err := rangeRefToCoordinates(ref)
if err != nil {
return cell, err
}
_ = sortCoordinates(rect)
ws.MergeCells.Cells[i].rect = rect
}
if cellInRange([]int{col, row}, ws.MergeCells.Cells[i].rect) {
The ref != "" condition means an empty ref skips the block that populates rect, so rect stays nil. The cellInRange call on the next line is unconditional and receives that nil slice.
Ref comes straight from xl/worksheets/sheetN.xml through encoding/xml, so an empty string is entirely attacker-controlled.
Any consumer that opens an untrusted workbook and reads a cell panics. The loop scans every merged cell, so any cell reference triggers it, not a specific one. Affected entry points include GetCellValue, GetCellType, GetCellFormula, SetCellValue and the in-cell branch of GetPictures. The streaming Rows and GetRows use the SAX path and do not go through this parser, and GetMergeCells routes through Rect() which errors cleanly, which is probably why this has not surfaced before.
There is no option or flag involved; opening the file succeeds and the panic fires on the first cell read. Unless the caller wraps the call in recover() it takes the process down.
This is a regression. Commit a34c81e (PR #1500, 2023-03-20) replaced checkCellInRangeRef, whose len(rng) != 2 guard returned cleanly for an empty ref, with the cached-rect fast path above, and the guard did not come along. git merge-base --is-ancestor confirms that commit is an ancestor of v2.11.0, so released versions are affected as well as HEAD.
Executed at HEAD.
Build a minimal xlsx whose xl/worksheets/sheet1.xml contains:
<mergeCells count="1"><mergeCell ref=""></mergeCell></mergeCells>
Then:
f, err := excelize.OpenReader(bytes.NewReader(data))
if err != nil { t.Fatal(err) }
_, _ = f.GetCellValue("Sheet1", "A1")
Observed, running against the repository at HEAD:
panic: runtime error: index out of range [0] with length 0
excelize.cellInRange cell.go:1691
excelize.(*xlsxWorksheet).mergeCellsParser cell.go:1660
excelize.(*File).getCellStringFunc cell.go:1512
excelize.(*File).GetCellValue cell.go:72
OpenReader itself returns no error; the file is 1656 bytes. A1, B1 and A2 all reproduce it.
For context on how targeted this is, I ran a battery of 38 crafted files covering data validation, conditional formatting, cell and row references, number formats, cols, hyperlinks, dimension, shared strings and tables. Only the empty-ref merge cell panicked; everything else returned a clean error. The other parsing paths look well guarded.
Skip the entry when the rectangle is empty, before the range test:
if len(ws.MergeCells.Cells[i].rect) == 0 {
continue
}
Credit goes to arpitjain099.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Go Vulnerability Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain · GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.