Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GHSA-q5j5-6p94-4gwc

Fix: qax-os/excelize#2331

GHSA-q5j5-6p94-4gwc is a Uncontrolled Resource Consumption vulnerability in github.com/xuri/excelize/v2. O3 Security confirms whether GHSA-q5j5-6p94-4gwc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Excelize: Streaming GetRows row-bound bypass causes attacker-controlled allocation

Also known asCVE-2026-59161
Published
Sep 10, 2026
Updated
Sep 10, 2026
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed
Exploitation data as of Sep 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

2 pkgs affected
🐹github.com/xuri/excelize/v2🐹github.com/xuri/excelize

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Streaming GetRows row-bound bypass causes attacker-controlled allocation

Summary

Excelize's prior row-bound fix for GHSA-h69g / CVE-2026-54063 protects the checked worksheet parser, but the streaming worksheet reader used by Rows and GetRows does not enforce the same TotalRows bound on the row r attribute. A small XLSX file can set a row number above Excelize's maximum row (1048576) and omit the cell coordinate. GetRows then appends empty rows up to the attacker-controlled row index and returns success.

This was reproduced on the current default branch commit 1213a8bd7c5ab360554603ac5c995ccaf6eb4314 and the latest release tag v2.10.1 (5ad5ab3af0054c55bdce09f1530085600e9f2e45).

Affected package

  • Package: github.com/xuri/excelize/v2
  • Tested affected versions: current default branch at 1213a8bd7c5ab360554603ac5c995ccaf6eb4314, and release v2.10.1
  • Fixed version: none known at the time of this report

Impact

An attacker who can provide an XLSX file to an application that calls GetRows can cause memory and CPU usage to scale with an attacker-controlled row number, even though the file itself is tiny. This is an availability issue and appears to be an incomplete coverage variant of the GHSA-h69g row-index allocation class.

In the conservative PoC, row r="2000000" returned a [][]string with length 2,000,000 and allocated about 46 MB. Larger row numbers scale the allocation further.

Root cause

The checked parser path validates row numbers:

  • excelize.go: checkRowNum(r int) rejects negative rows and rows greater than TotalRows.
  • excelize.go: checkSheet() calls checkRowNum(r.R) before allocating sheet rows.
  • workSheetReader() invokes checkSheet() / checkRow() before returning a cached worksheet.

The streaming path does not use that checked parser:

  • rows.go: Rows(sheet) opens an XML decoder directly.
  • Rows.Next() accepts the row r attribute and assigns it to the iterator's current row without applying checkRowNum().
  • Rows.Columns() also assigns row r to the iterator state without applying checkRowNum().
  • GetRows() appends empty row slices for the gap between the previous row and the current row.

Because a cell without an r coordinate can still contain a value, the worksheet can avoid cell-coordinate row validation while still causing GetRows() to materialize rows up to the out-of-range row number.

Minimal worksheet payload

<?xml version="1.0" encoding="UTF-8"?>
<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
  <sheetData>
    <row r="2000000"><c t="s"><v>0</v></c></row>
  </sheetData>
</worksheet>

The workbook also contains a normal sharedStrings.xml with one string (ok).

Reproduction

A minimal Go harness creates the XLSX in memory and calls GetRows("Sheet1"):

rows, err := f.GetRows("Sheet1")
fmt.Println("rows_len:", len(rows))
if len(rows) > 0 {
    fmt.Println("last_row:", rows[len(rows)-1])
}
fmt.Printf("returned error: %T %v\n", err, err)

Observed output on current default branch commit 1213a8bd7c5ab360554603ac5c995ccaf6eb4314:

== streaming GetRows row r=2000000 cell without r ==
rows_len: 2000000
last_row: [ok]
returned error: <nil> <nil>
elapsed=21ms alloc_delta=46MB

Observed output on latest release tag v2.10.1:

== streaming GetRows row r=2000000 cell without r ==
rows_len: 2000000
last_row: [ok]
returned error: <nil> <nil>
elapsed=14ms alloc_delta=46MB

A control using the checked parser with row r="1048577" and c r="A1048577" correctly returns row number exceeds maximum limit, confirming this report is about inconsistent enforcement in the streaming path rather than a missing global constant.

Expected behavior

Rows / GetRows should reject row numbers greater than TotalRows with the same error behavior as the checked parser path.

Suggested remediation

  • Apply the same row-bound validation in the streaming reader immediately after parsing a row r attribute.
  • Preserve and return row parsing errors from GetRows() instead of silently continuing or returning only Rows.Close() errors.
  • Add regression tests for GetRows() on a worksheet containing row r="1048577" with a cell value but no cell r coordinate.

Affected Packages

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/xuri/excelize/v2all versions2.11.0
🐹Gogithub.com/xuri/excelizeall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/xuri/excelize/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/xuri/excelize/v2 to 2.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q5j5-6p94-4gwc is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-q5j5-6p94-4gwc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-q5j5-6p94-4gwc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

# Streaming GetRows row-bound bypass causes attacker-controlled allocation ## Summary Excelize's prior row-bound fix for GHSA-h69g / CVE-2026-54063 protects the checked worksheet parser, but the streaming worksheet reader used by `Rows` and `GetRows` does not enforce the same `TotalRows` bound on the row `r` attribute. A small XLSX file can set a row number above Excelize's maximum row (`1048576`) and omit the cell coordinate. `GetRows` then appends empty rows up to the attacker-controlled row index and returns success. This was reproduced on the current default branch commit `1213a8bd7c5ab
O3 Security · Impact-Aware SCA

Is GHSA-q5j5-6p94-4gwc in your dependencies?

O3 detects GHSA-q5j5-6p94-4gwc across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-q5j5-6p94-4gwc: v2 | O3 Security