Summary
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:967ws.SheetData.Row[rowIdx].C[colNum-1] = *colDatainsidecheckRow. checkRowcomputeslastColfrom the column of the last cell in document order (rows.go:940), allocatestargetListof that length, then re-scatters every source cell intoC[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:
<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:
rg -n "func checkRow|lastCol|Row\[rowIdx\].C\[colNum-1\]" rows.go
Impact
A write operation targets a memory location beyond the intended buffer boundary. Typical impact: memory corruption, crash, or arbitrary code execution.
CVE-2026-107221 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.20260816084418-46a5eb289448); 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
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.
Frequently Asked Questions
- What is CVE-2026-107221? CVE-2026-107221 is a medium-severity out-of-bounds write vulnerability in github.com/xuri/excelize/v2 (go), affecting versions >= 2.0.0, < 2.11.1-0.20260816084418-46a5eb289448. It is fixed in 2.11.1-0.20260816084418-46a5eb289448. A write operation targets a memory location beyond the intended buffer boundary.
- How severe is CVE-2026-107221? CVE-2026-107221 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-107221? github.com/xuri/excelize/v2 (go) versions >= 2.0.0, < 2.11.1-0.20260816084418-46a5eb289448 is affected.
- Is there a fix for CVE-2026-107221? Yes. CVE-2026-107221 is fixed in 2.11.1-0.20260816084418-46a5eb289448. Upgrade to this version or later.
- Is CVE-2026-107221 exploitable, and should I be worried? Whether CVE-2026-107221 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-107221 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-107221? Upgrade
github.com/xuri/excelize/v2to 2.11.1-0.20260816084418-46a5eb289448 or later.