GHSA-FQ3V-74GV-27GM
Vulnerability from github – Published: 2026-10-07 20:22 – Updated: 2026-10-07 20:22Summary
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:
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.
<cols><col min="1" max="2147483647" width="9"/></cols>
f.SetColWidth("Sheet1", "A", "A", 12)
Measured:
max="300000": 46.2 s CPU, 122 MB allocated,ws.Cols.Colgrew 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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/xuri/excelize/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.11.1-0.20260807015645-a54c578af309"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107223"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:22:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe `max` attribute of a `\u003ccol\u003e` 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.\n\nConfirmed at `ae2113b` (HEAD at the time of audit).\n\n### Details\n\n`col.go:547`, `flatCols()`, with the two loops at `:549` and `:564`:\n\n```go\nfor i := col.Min; i \u003c= col.Max; i++ {\n...\nfor i := column.Min; i \u003c= column.Max; i++ { ... fc = append(fc, deepcopy.Copy(...)) }\n```\n\n`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.\n\nThe 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\u0027s validated argument never constrains the loop. The crafted column expands no matter which column the caller touches.\n\nThe row axis has the guard this axis is missing: GHSA-h69g-9hx6-f3v4 capped `checkSheet`\u0027s row allocation at `TotalRows`, and GHSA-q5j5-6p94-4gwc capped streaming `Rows.Next`. There is no column-axis equivalent.\n\nPublic 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`).\n\n### PoC\n\nExecuted in-package: crafted a real xlsx, rezipped with an injected `\u003ccols\u003e` block before `\u003csheetData\u003e`, opened it with `OpenReader`, then called `SetColWidth`.\n\n```xml\n\u003ccols\u003e\u003ccol min=\"1\" max=\"2147483647\" width=\"9\"/\u003e\u003c/cols\u003e\n```\n\n```go\nf.SetColWidth(\"Sheet1\", \"A\", \"A\", 12)\n```\n\nMeasured:\n\n- `max=\"300000\"`: 46.2 s CPU, 122 MB allocated, `ws.Cols.Col` grew to 300000 entries, from one call.\n- `max=\"5000000\"`: did not complete in 110 s, killed by the test timeout.\n\nGrowth 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.\n\n### Impact\n\nAny 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.\n\n### Suggested fix\n\nValidate `col.Min` and `col.Max` against `MinColumns`/`MaxColumns` when parsing the `\u003ccol\u003e` element, or at the top of `flatCols`, returning `ErrColumnNumber` for out-of-range values. That mirrors what `checkRowNum` already does on the row axis.\n\n### Why this is not GHSA-h69g-9hx6-f3v4 or GHSA-q5j5-6p94-4gwc\n\nBoth of those are row-axis allocation bounds, and both fixes cap at `TotalRows`. Neither touched `\u003ccol\u003e` 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.",
"id": "GHSA-fq3v-74gv-27gm",
"modified": "2026-10-07T20:22:49Z",
"published": "2026-10-07T20:22:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/security/advisories/GHSA-fq3v-74gv-27gm"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/pull/2370"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/commit/a54c578af309fa81f448143ed2b7a91192cc58a7"
},
{
"type": "PACKAGE",
"url": "https://github.com/qax-os/excelize"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Excelize: Unbounded \u003ccol max\u003e attribute is loaded with no MaxColumns check and expanded per-column by flatCols(), so any column mutator hangs or OOMs the process"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.