CVE-2026-107213 · GHSA-r7x5-4969-99p7
Excelize: Nil-pointer dereference in GetSlicers when a worksheet has extLst present but no drawing element
- Risk score
- 45/100
- CVSS
- 5.5 v3.1
- Exploit chance (30 days)
- 0.2%
- 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.9.0 to 2.11.0, GetSlicers checks for ExtLst but dereferences ws.Drawing without checking whether the independently optional drawing element exists. File.GetSlicers reads ws.Drawing.RID after seeing a worksheet extLst element…
- Affected
- github.com/xuri/excelize/v2 (go) >= 2.9.0, < 2.11.1-0.20260929015830-8ffeb07ec9a3
- Fix
- Upgrade github.com/xuri/excelize/v2 to 2.11.1-0.20260929015830-8ffeb07ec9a3 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-107213: Excelize: Nil-pointer dereference in GetSlicers when a worksheet has extLst present but no drawing element (CVSS 5.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-107212: Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days (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%)
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: Null pointer dereference (CWE-476). 91 other warnings in 30 days
- Same product: Earlier github.com/xuri/excelize/v2 warnings. 11 in the last 90 days
Why it is Yellow
- CVSS 5.5 medium
- Public exploit or proof of concept referenced
- On your watchlist: Go
Affected packages
| Package | Ecosystem | Vulnerable | Fixed in |
|---|---|---|---|
| github.com/xuri/excelize/v2 | go | >= 2.9.0, < 2.11.1-0.20260929015830-8ffeb07ec9a3 | 2.11.1-0.20260929015830-8ffeb07ec9a3 |
References
- https://github.com/advisories/GHSA-r7x5-4969-99p7
- https://github.com/qax-os/excelize/security/advisories/GHSA-r7x5-4969-99p7
- https://nvd.nist.gov/vuln/detail/CVE-2026-107213
- https://github.com/qax-os/excelize/pull/2434
- https://github.com/qax-os/excelize/commit/8ffeb07ec9a350410f6922313f6b7e4f5cc79241
- https://github.com/advisories/GHSA-r7x5-4969-99p7
Original description
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.9.0 to 2.11.0, GetSlicers checks for ExtLst but dereferences ws.Drawing without checking whether the independently optional drawing element exists. File.GetSlicers reads ws.Drawing.RID after seeing a worksheet extLst element even when the independently optional worksheet drawing element is absent. When a crafted worksheet contains an extLst element without a drawing element and the application calls GetSlicers, the nil ws.Drawing pointer is dereferenced while resolving the drawing relationship, allowing an attacker to panic and terminate an unprotected process. No fixed version is available as of this review.
Last activity 7 Oct 2026. Patch Forecast updates every hour.