CVE-2026-107212 · GHSA-jw42-f3rr-4cc3
Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days
- Risk score
- 65/100
- CVSS
- 7.5 v3.1
- Exploit chance (30 days)
- 0.3%
- Published
- 7 Oct 2026
Open in the live forecast Today's forecast
What to know
- What it is
- Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, Rows.Columns accepts a look-ahead row number above TotalRows without applying the limit enforced by Rows.Next. File.GetRows relies on Rows.Next and Rows.Columns, but Rows.Columns consumes the row r attribute w…
- Affected
- github.com/xuri/excelize/v2 (go) >= 2.1.0, < 2.11.1-0.20260930021559-01a9ff32fb3c
- Fix
- Upgrade github.com/xuri/excelize/v2 to 2.11.1-0.20260930021559-01a9ff32fb3c or later.
- Exploitation
- Public proof of concept
Story map
At a glance
github.com/xuri/excelize/v2: Amber, patch this week. Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, flatCols expands file-loaded column ranges without validating Min and Max against the worksheet column limit. SetColWidth reaches flatCols, which expands xlsxCol.Min through xlsxCol.Max without enforcing MaxCo…
The flaws
- CVE-2026-107212: Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days (CVSS 7.5 · EPSS 0%)
- CVE-2026-107223: Excelize: Unbounded <col max> attribute is loaded with no MaxColumns check and expanded per-column by flatCols(), so any column mutator hangs or OOMs the process (CVSS 7.5 · EPSS 0%)
- CVE-2026-107217: Excelize ColumnNameToNumber: int64 overflow yields an out-of-domain coordinate with nil error, causing negative slice index panic on r="0" rows (CVSS 7.5 · EPSS 0%)
- CVE-2026-107219: Excelize: Unbounded spinCount in agile decryption burns CPU during OpenFile (CVSS 7.5 · EPSS 0%)
The fix
Fix: Upgrade github.com/xuri/excelize/v2 to 2.11.1-0.20260807015645-a54c578af309 or later.
Who is exposed: github.com/xuri/excelize/v2 (go) >= 2.1.0, < 2.11.1-0.20260807015645-a54c578af309
Where it stands
- Public proof of concept
Connects to
- Same weakness: Denial of service (CWE-770). 202 other warnings in 30 days
- Same product: Earlier github.com/xuri/excelize/v2 warnings. 11 in the last 90 days
Why it is Amber
- CVSS 7.5 high
- Public exploit or proof of concept referenced
- Remotely exploitable without logging in
- On your watchlist: Go
Affected packages
| Package | Ecosystem | Vulnerable | Fixed in |
|---|---|---|---|
| github.com/xuri/excelize/v2 | go | >= 2.1.0, < 2.11.1-0.20260930021559-01a9ff32fb3c | 2.11.1-0.20260930021559-01a9ff32fb3c |
References
- https://github.com/advisories/GHSA-jw42-f3rr-4cc3
- https://github.com/qax-os/excelize/security/advisories/GHSA-jw42-f3rr-4cc3
- https://nvd.nist.gov/vuln/detail/CVE-2026-107212
- https://github.com/qax-os/excelize/pull/2438
- https://github.com/qax-os/excelize/commit/01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23
- https://github.com/advisories/GHSA-jw42-f3rr-4cc3
Original description
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, Rows.Columns accepts a look-ahead row number above TotalRows without applying the limit enforced by Rows.Next. File.GetRows relies on Rows.Next and Rows.Columns, but Rows.Columns consumes the row r attribute without the limit check in Rows.Next. When a crafted worksheet places an oversized row number after an ordinary valid row and the application calls GetRows or iterates Rows, the iterator advances through every missing row number instead of rejecting the workbook, allowing an attacker to consume a CPU core for an attacker-controlled duration. No fixed version is available as of this review.
Last activity 7 Oct 2026. Patch Forecast updates every hour.