CVE-2026-107223 is a high severity denial of service (CVSS 7.5) in Excelize, the Go library for Excel files. A crafted worksheet with an oversized column range can exhaust CPU and memory when the application changes a column. The GitHub advisory lists version 2.11.1 as the fix.
What's affected
Source conflict on the fix. The record says versions from 2.1.0 to 2.11.0 are affected and states that no fixed version is available as of its review. The GitHub advisory GHSA-fq3v-74gv-27gm, published on 7 August 2026, lists the Go module github.com/xuri/excelize/v2 with affected versions from 2.1.0 up to and including 2.11.0 and a patched version of 2.11.1. The advisory is the newer statement, so plan on 2.11.1, and confirm that the tag exists in the module proxy before you pin it.
The weakness is CWE-789, memory allocation with an excessive size value. The vector is network reachable, with no privileges and no user interaction, and only availability is affected.
You are exposed if your service opens workbooks from untrusted sources and then calls one of the column mutator functions. The advisory names SetColWidth, SetColStyle, SetColVisible and SetColOutlineLevel. A service that only reads cell values may not reach the vulnerable function.
How to check if you're exposed
See which version your module resolves:
go list -m github.com/xuri/excelize/v2
go mod why -m github.com/xuri/excelize/v2
The first shows the version in your build and the second shows which package imports it. A result from 2.1.0 to 2.11.0 is in the affected range.
Next, search your code for the four functions the advisory lists:
grep -rn -E "SetColWidth|SetColStyle|SetColVisible|SetColOutlineLevel" --include=*.go .
If a match sits on a path that handles an uploaded workbook, you have a reachable call. A match in a report generator that builds a file from scratch is less urgent, since the oversized range comes from a file loaded from outside.
What to do now
- Upgrade to github.com/xuri/excelize/v2 version 2.11.1 with
go get github.com/xuri/excelize/v2@v2.11.1, then run your tests and rebuild. - Confirm the new version with
go list -min the build that ships, and vendor the module again if you vendor. - Put a size limit on uploaded workbooks and a time limit on processing, so one bad file cannot pin a worker.
- Run spreadsheet processing in a separate process or container with CPU and memory limits.
- Review other places where your service opens untrusted office files and apply the same limits.
Why it matters
A worksheet stores column settings as ranges with a minimum and a maximum. Excelize reads these numbers straight from the file and, when you change a column, expands the range into one entry per column. Excel itself stops at 16384 columns, but according to the advisory the file loading code never compared the numbers against that limit. A file that says the range runs to a billion makes the library build a billion entries.
The advisory contrasts this with the row direction, where earlier advisories had added the missing cap. The column direction lacked an equivalent. That is a typical shape for resource exhaustion bugs: one axis gets a guard after a report, and the twin axis gets forgotten.
The damage is availability only, but a single request can hold a CPU for a long time or end the process with an out of memory kill. The advisory reports that a modest oversized value cost tens of seconds of CPU on one call. The record does not mark the CVE as known exploited.
Try it yourself
See how this kind of finding shows up in a dependency workflow.
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes it?
The advisory says 2.11.1. The record says no fix was available when it was reviewed, so confirm the tag before pinning.
Does a service that only reads cells need to worry?
The advisory ties the problem to column mutator functions. Check your code for those calls.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
