---
id: "CVE-2026-107223"
page: "https://infrastack.ai/live/CVE-2026-107223"
kind: "vulnerability"
aliases: ["CVE-2026-107223", "GHSA-fq3v-74gv-27gm", "GO-2026-6678"]
title: "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"
severity: "high"
cvss: 7.5
epss: 0.0037
exploited: false
status: "open"
category: "package"
products: [{"name": "github.com/360EntSecGroup-Skylar/excelize/v2", "fixed": [], "affected": ">= 2.1.0", "ecosystem": "go"}, {"name": "github.com/xuri/excelize/v2", "fixed": ["2.11.1-0.20260807015645-a54c578af309"], "affected": "< 2.11.1-0.20260807015645-a54c578af309", "ecosystem": "go"}, {"name": "excelize", "fixed": [], "affected": ">= 2.1.0, <= 2.11.0", "ecosystem": "vendor"}, {"name": "github.com/xuri/excelize/v2", "fixed": ["2.11.1-0.20260807015645-a54c578af309"], "affected": ">= 2.1.0, < 2.11.1-0.20260807015645-a54c578af309", "ecosystem": "go"}]
ecosystems: ["go", "vendor"]
tags: ["backend", "cwe-789", "document-processing", "excelize", "go", "package"]
not_affected_if: ["no-column-mutators", "trusted-input-only"]
published_at: "2026-10-07T19:17:34+00:00"
first_seen_at: "2026-11-06T00:09:03+00:00"
updated_at: "2026-11-06T00:19:08+00:00"
sources: [{"source": "govuln", "url": "https://pkg.go.dev/vuln/GO-2026-6678", "first_seen_at": "2026-11-06T00:09:03+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107223", "first_seen_at": "2026-11-06T00:19:01+00:00"}, {"source": "ghsa", "url": "https://github.com/advisories/GHSA-fq3v-74gv-27gm", "first_seen_at": "2026-11-06T00:19:08+00:00"}]
exploit_sources: [{"type": "epss", "score": 0.0037, "url": "https://api.first.org/data/v1/epss?cve=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

Link for people: https://infrastack.ai/live/CVE-2026-107223 (this .md is for agents)

A crafted spreadsheet with an oversized column max value makes the Go excelize library's column functions loop without a column limit. An attacker can cause a hang or out-of-memory crash in a service that opens and edits untrusted workbooks.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/360EntSecGroup-Skylar/excelize/v2 affected >= 2.1.0 fixed no fixed version listed
- go:github.com/xuri/excelize/v2 affected < 2.11.1-0.20260807015645-a54c578af309 fixed 2.11.1-0.20260807015645-a54c578af309
- vendor:excelize affected >= 2.1.0, <= 2.11.0 fixed no fixed version listed
- go:github.com/xuri/excelize/v2 affected >= 2.1.0, < 2.11.1-0.20260807015645-a54c578af309 fixed 2.11.1-0.20260807015645-a54c578af309

## How to check

- Check the excelize version in `go.mod` for `github.com/xuri/excelize/v2`.
- Check whether the code opens untrusted .xlsx files and calls column functions such as SetColWidth or SetColVisible.
- The fork path github.com/360EntSecGroup-Skylar/excelize/v2 may also be in use; check `go.mod` for it.

## Fix

- `github.com/xuri/excelize/v2` fixed in `2.11.1-0.20260807015645-a54c578af309`.
- Fixed version for the 360EntSecGroup-Skylar fork: unknown.

## Timeline

- 2026-11-06T00:09:03+00:00 govuln https://pkg.go.dev/vuln/GO-2026-6678
- 2026-11-06T00:19:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-107223
- 2026-11-06T00:19:08+00:00 ghsa https://github.com/advisories/GHSA-fq3v-74gv-27gm

## Documents

- [advisory] Vendor advisory: github.com https://github.com/qax-os/excelize/security/advisories/GHSA-fq3v-74gv-27gm
- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/qax-os/excelize/security-advisories/GHSA-fq3v-74gv-27gm
- [fix] Patch: github.com https://github.com/qax-os/excelize/commit/a54c578af309fa81f448143ed2b7a91192cc58a7
- [fix] Patch: github.com https://github.com/qax-os/excelize/pull/2370

## From the sources

### Summary

The `max` attribute of a `<col>` element in `xl/worksheets/sheetN.xml` is read verbatim on open with no check against `MaxColumns`, and `flatCols()` then walks `Min..Max` doing a `deepcopy.Copy` and `append` per iteration. Executed: `max="300000"`, only about 18x past the real 16384 limit, cost 46.2 s of CPU and 122 MB on a single `SetColWidth` call, and the growth is linear in `max` up to 2^31-1.

Confirmed at `ae2113b` (HEAD at the time of audit).

### Details

`col.go:547`, `flatCols()`, with the two loops at `:549` and `:564`:

```go
for i := col.Min; i <= col.Max; i++ {
...
for i := column.Min; i <= column.Max; i++ { ... fc = append(fc, deepcopy.Copy(...)) }
```

`column.Min` and `column.Max` are plain int attributes on `xmlWorksheet.go:279-280`, bound straight from the file. `MaxColumns` is 16384 (`templates.go:176`) and nothing in the parse path compares against it.

The contrast that makes this an oversight rather than a design decision is inside the callers themselves. `SetColWidth` validates its own column argument through `parseColRange`, which clamps to `MaxColumns`. But `flatCols` iterates `ws.Cols.Col`, the file-loaded slice, so the caller's validated argument never constrains the loop. The crafted column expands no matter which column the caller touches.

The row axis has the guard this axis is missing: GHSA-h69g-9hx6-f3v4 capped `checkSheet`'s row allocation at `TotalRows`, and GHSA-q5j5-6p94-4gwc capped streaming `Rows.Next`. There is no column-axis equivalent.

Public entry points that flatten the existing columns: `SetColWidth` (`col.go:498` into `:534`), `SetColStyle` (`col.go:431` into `:477`), `SetColVisible` (`col.go:282` into `:313`), `SetColOutlineLevel` (`col.go:376` into `:407`).

### PoC

Executed in-package: crafted a real xlsx, rezipped with an injected `<cols>` block before `<sheetData>`, opened it with `OpenReader`, then called `SetColWidth`.

```xml
<cols><col min="1" max="2147483647" width="9"/></cols>
```

```go
f.SetColWidth("Sheet1", "A", "A", 12)
```

Measured:

- `max="300000"`: 46.2 s CPU, 122 MB allocated, `ws.Cols.Col` grew to 300000 entries, from one call.
- `max="5000000"`: did not complete in 110 s, killed by the test timeout.

Growth is linear in `max`. At `max=2147483647` that is roughly two billion `xlsxCol` allocations, which is hundreds of gigabytes and in practice a permanent hang ending in OOM.

### Impact

Any service that opens an untrusted spreadsheet and calls a column mutator. The input is a few dozen bytes of XML inside an otherwise ordinary workbook, no authentication is involved beyond whatever gates the upload, and the process is either wedged for minutes or killed by the OOM reaper. Availability only; no read or write primitive here.

### Suggested fix

Validate `col.Min` and `col.Max` against `MinColumns`/`MaxColumns` when parsing the `<col>` element, or at the top of `flatCols`, returning `ErrColumnNumber` for out-of-range values. That mirrors what `checkRowNum` already does on the row axis.

### Why this is not GHSA-h69g-9hx6-f3v4 or GHSA-q5j5-6p94-4gwc

Both of those are row-axis allocation bounds, and both fixes cap at `TotalRows`. Neither touched `<col>` parsing or `flatCols`. This is the same weakness class on the column axis, and it is arguably worse than the two that were fixed, because those had a cap that was bypassed while this one has no cap at all.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_