CVE-2026-107220: Excelize: Panic in cellInRange on a worksheet with an empty mergeCell ref
Summary
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.
Where it is
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, mergeCellsParser
if 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.
Impact
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.
Proof of concept
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.
Suggested fix
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.
Other sources
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.7.1 to 2.11.0, mergeCellsParser leaves the cached rectangle empty for an empty mergeCell ref and then passes that empty slice to cellInRange without a length check. GetCellValue reaches mergeCellsParser, which passes an empty rectangle derived from the mergeCell ref attribute into cellInRange. When a crafted worksheet contains an empty mergeCell ref and a non-streaming cell API reads the worksheet, cellInRange indexes four positions in an empty slice, allowing an attacker to panic on the first affected cell operation. 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.20260820023833-99903a3240e5 - Compensating control
In mergeCellsParser, skip the entry when ws.MergeCells.Cells[i].rect is empty before calling cellInRange; add an empty-rectangle guard so an empty mergeCell ref cannot be indexed.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using Excelize versions 2.7.1 through 2.11.0 are exposed when they read attacker-controlled or otherwise malformed worksheets using a non-streaming cell API. The crafted worksheet must contain a mergeCell element with an empty ref attribute.
What does an attacker need to do to trigger the failure?
An attacker needs to provide a worksheet containing an empty mergeCell ref and cause the application to perform a non-streaming cell read, such as GetCellValue. The first affected cell operation can panic, resulting in denial of service.
Is a patch available?
No fixed version was available as of the review. The affected range is stated as Excelize 2.7.1 through 2.11.0.
What can be done if patching is not immediately possible?
Avoid processing untrusted worksheets with affected non-streaming cell APIs, or validate and reject worksheets that contain mergeCell elements with empty ref attributes before passing them to Excelize.