Summary
Excelize: Panic in cellInRange on a worksheet with an empty mergeCell ref
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.
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.
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.
A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.
CVE-2026-107220 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.11.1-0.20260820023833-99903a3240e5); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-107220? CVE-2026-107220 is a medium-severity out-of-bounds read vulnerability in github.com/xuri/excelize/v2 (go), affecting versions >= 2.7.1, < 2.11.1-0.20260820023833-99903a3240e5. It is fixed in 2.11.1-0.20260820023833-99903a3240e5. A read operation accesses a memory location beyond the intended buffer boundary.
- How severe is CVE-2026-107220? CVE-2026-107220 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/xuri/excelize/v2 are affected by CVE-2026-107220? github.com/xuri/excelize/v2 (go) versions >= 2.7.1, < 2.11.1-0.20260820023833-99903a3240e5 is affected.
- Is there a fix for CVE-2026-107220? Yes. CVE-2026-107220 is fixed in 2.11.1-0.20260820023833-99903a3240e5. Upgrade to this version or later.
- Is CVE-2026-107220 exploitable, and should I be worried? Whether CVE-2026-107220 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-107220 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-107220? Upgrade
github.com/xuri/excelize/v2to 2.11.1-0.20260820023833-99903a3240e5 or later.