CVE-2026-54063: Excelize Library DOS Vulnerability

CVE-2026-54063 Overview

CVE-2026-54063 is a denial-of-service vulnerability in Excelize, a Go language library for reading and writing Microsoft Excel spreadsheets. The flaw resides in the checkSheet() function within github.com/xuri/excelize/v2, which uses an attacker-controlled <row r="N"> XML attribute directly as the length argument to make([]xlsxRow, row). The library fails to validate this value against the Excel row limit of 1,048,576. A crafted XLSX file triggers either a ~16 GB memory allocation or a runtime panic. Any service that opens attacker-supplied XLSX files and calls GetCellValue is affected. No authentication is required. The issue is fixed in Excelize version 2.11.0.

Critical Impact
Attackers can remotely crash any Go service that parses untrusted XLSX files by supplying a single malicious spreadsheet, with no authentication required.

Affected Products

Excelize (github.com/xuri/excelize/v2) versions prior to 2.11.0
Go applications and services that ingest untrusted XLSX files via Excelize
Web services calling GetCellValue on user-uploaded spreadsheets

Discovery Timeline

2026-07-10 - CVE-2026-54063 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-54063

Vulnerability Analysis

The vulnerability is classified under [CWE-770] Allocation of Resources Without Limits or Throttling. Excelize parses the r attribute of the <row> element inside an XLSX file's XML sheet data and passes the integer directly to Go's make built-in to preallocate a slice of xlsxRow structs. Because the value originates from attacker-controlled input, the library trusts unbounded integer values without comparing them to the Excel maximum row count of 1,048,576.

Two denial-of-service variants exist. First, setting r=2147483647 (the maximum signed 32-bit integer) forces the runtime to attempt an allocation of roughly 16 GB, triggering an out-of-memory kill by the operating system or container runtime. Second, setting r=-1 produces a negative length that leads to out-of-bounds slice indexing and a runtime panic. Both variants terminate the host process.

Root Cause

The root cause is missing input validation on an untrusted XML attribute before it is used as a slice length. The checkSheet() function should clamp or reject row indices outside the valid Excel range but instead treats them as authoritative. Go's make panics on negative lengths and consumes host memory on excessive positive lengths, converting a parsing bug into a reliable crash primitive.

Attack Vector

Exploitation requires only that a target service accept and open an XLSX file provided by the attacker, then invoke GetCellValue or another API path that reaches checkSheet(). Common attack surfaces include document ingestion pipelines, report converters, spreadsheet import features in SaaS applications, and email attachment scanners. The attack is network-reachable, requires no privileges, and no user interaction beyond the normal file upload flow. See the GitHub Security Advisory GHSA-h69g-9hx6-f3v4 for the maintainer's technical description.

Detection Methods for CVE-2026-54063

Indicators of Compromise

XLSX files containing <row r="2147483647"> or other extreme positive integer values in xl/worksheets/sheet*.xml
XLSX files containing negative r attributes such as <row r="-1">
Repeated OOM-killer events or Go runtime panic stack traces referencing checkSheet or xlsxRow

Detection Strategies

Inspect uploaded XLSX archives by unzipping and scanning sheet XML for rowr attributes outside the range 1 to 1,048,576.
Monitor Go service logs for panics containing runtime error: makeslice: len out of range or signal: killed correlated with spreadsheet processing.
Instrument the file ingestion service with resident set size (RSS) alerts to catch sudden multi-gigabyte allocations tied to a single request.

Monitoring Recommendations

Log the source IP, user identity, and file hash for every XLSX upload to enable retrospective hunting once indicators are known.
Alert on process restarts and OOM events from container orchestrators such as Kubernetes when they coincide with document parsing workloads.
Track the dependency version of github.com/xuri/excelize/v2 across build pipelines using software composition analysis to identify unpatched services.

How to Mitigate CVE-2026-54063

Immediate Actions Required

Upgrade github.com/xuri/excelize/v2 to version 2.11.0 or later in all Go modules and rebuild affected binaries.
Audit all services that accept XLSX uploads and confirm the resolved dependency version using go list -m all.
Enforce strict file size limits and per-request memory limits on any endpoint that parses spreadsheets.

Patch Information

The fix is included in Excelize v2.11.0, released on the project's GitHub repository. The patched checkSheet() function validates the row attribute against the Excel row maximum before allocating the slice. Refer to the Excelize v2.11.0 release notes for the full changelog and to the GHSA-h69g-9hx6-f3v4 advisory for advisory details.

Workarounds

Pre-validate uploaded XLSX files by unzipping and rejecting any sheet XML whose <row>r attribute is less than 1 or greater than 1,048,576.
Run the parsing component in a sandboxed process with strict memory cgroup limits so an OOM kill does not affect the parent service.
Restrict spreadsheet uploads to authenticated users and apply rate limits to reduce the volume of malicious submissions.

bash

# Update Excelize to the patched version
go get github.com/xuri/excelize/v2@v2.11.0
go mod tidy
go build ./...

# Verify the resolved version
go list -m github.com/xuri/excelize/v2