CVE-2026-107212: CPU Exhaustion Denial of Service via Look-Ahead Row Parsing in Excelize

Excelize is an open-source Go language library designed for reading, writing, and processing Microsoft Excel spreadsheets. The library is optimized for handling high-volume data structures and relies heavily on a streaming XML tokenizer to limit memory consumption when parsing large OpenXML workbooks.

Applications that accept user-uploaded files often leverage Excelize to parse spreadsheet data on the backend. This exposes an attack surface where untrusted input files are parsed automatically. If a worksheet contains structural or architectural violations in its XML metadata, the parsing engine must resolve these states cleanly without exhausting host resources.

This vulnerability, tracked as CVE-2026-107212, is an algorithmic complexity flaw within the look-ahead logic of the row processing module. An attacker can supply a crafted Excel document where the row index attribute deviates from sequential ordering and exceeds the architectural row limit. This causes the internal row iterator to enter an unbounded processing loop, resulting in persistent CPU exhaustion.

Microsoft Excel spreadsheets limit the maximum index of a worksheet row to 1,048,576, which is defined in Excelize as the constant TotalRows. To traverse the underlying XML document sequentially, Excelize couples two main functions: Rows.Next() and Rows.Columns(). While Rows.Next() verifies that the index does not exceed this boundary, the look-ahead logic inside Rows.Columns() contains a distinct code path that reads index values directly.

When Rows.Columns() parses the worksheet XML, it scans ahead to map the columns belonging to the active row. During this look-ahead scan, it reads the row number directly from the raw XML attribute r using the helper attrValToInt(). In affected versions of Excelize, this look-ahead sequence did not validate if the parsed row index value exceeded the TotalRows limit.

When an XML workbook contains a second row with an out-of-bounds index, such as 231999999999940, the look-ahead parser assigns this value directly to the internal state variable rows.curRow. In the subsequent iteration, Rows.Next() attempts to advance to the next index by checking the status of rows.seekRow against rows.curRow to determine if a fast-forward seek is required.

Because rows.curRow contains the oversized, unvalidated value, the conditional check rows.curRow >= rows.seekRow evaluates to true. The iterator continuously increments the internal tracking pointer rows.seekRow in a sequential loop, attempting to reach the massive integer value stored in rows.curRow. This sequence runs indefinitely, consuming 100% of the executing CPU thread.

The vulnerability resides in rows.go within the Columns() and Next() method implementations. The code below illustrates the look-ahead logic in Rows.Columns() before the fix:

// Vulnerable logic in rows.go
if rowIterator.inElement == "row" {
    rowNum := 0
    if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
        rows.curRow = rowNum
    } else if rows.token == nil {
        rows.curRow++
    }
}

The code above parses the r attribute and assigns it directly to rows.curRow without checking if the parsed index exceeds TotalRows. Commit 01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23 resolves this by adding an explicit upper bound comparison:

// Patched logic in rows.go
if rowIterator.inElement == "row" {
    rowNum := 0
    if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum > TotalRows {
        rows.err, rows.token = ErrMaxRows, nil
        return rowIterator.cells, rows.err
    } else if rowNum != 0 {
        rows.curRow = rowNum
    } else if rows.token == nil {
        rows.curRow++
    }
}

Additionally, the patch implements a critical short-circuit check at the entry point of the Rows.Next() function. This ensures that any error state flagged during look-ahead parsing immediately terminates the iteration:

// Patched logic in Next()
func (rows *Rows) Next() bool {
    if rows.err != nil {
        return false
    }
    rows.seekRow++
    // ...
}

By forcing an immediate exit when rows.err is populated with ErrMaxRows, the parsing engine halts execution immediately. This prevents the execution flow from falling into the sequential lookup loop, entirely neutralizing the CPU exhaustion vector.

An attacker can exploit this vulnerability by submitting a highly structured XLSX archive that targets the look-ahead mechanism. The exploit does not require authentication and can be completed via standard file-upload vectors.

To construct the payload, an attacker creates an Excel file and unpacks its structures to locate xl/worksheets/sheet1.xml. Inside this document, the attacker inserts a valid first row followed immediately by an out-of-bounds row index:

<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
  <sheetData>
    <row r="1">
      <c><v>First</v></c>
    </row>
    <row r="5000000000">
      <c><v>Trigger</v></c>
    </row>
  </sheetData>
</worksheet>

Once the archive is re-compressed and uploaded to a target application, the processing service executes the Excelize reading routine. The loop sequentially processes the first row cleanly. During look-ahead processing of the first row, Rows.Columns() reads the next element in the token stream and encounters the row with index 5000000000.

Because the index is not validated, the parser assigns 5000000000 to rows.curRow. When the application calls Rows.Next() to fetch the subsequent row, the validation check enters a loop where rows.seekRow increments from 2 towards 5000000000. This causes the executing Go routine to hang indefinitely, pinning the host CPU core.

The impact of CVE-2026-107212 is a sustained Denial of Service on the affected host. Because Excelize is often implemented in synchronous upload handling paths, a single malicious file upload will lock a processing thread and drive host CPU core usage to 100% capacity.

In multi-tenant cloud environments or microservice architectures, multiple automated uploads can quickly exhaust all available CPU resources across instances. This degrades the performance of surrounding services, causes request timeouts, and leads to system-wide instability.

This vulnerability has a CVSS v3.1 base score of 7.5. Since the exploit is contained entirely within the structure of the input file, it requires no privileges, can be executed over the network without user interaction, and has low attack complexity. Although it does not compromise data confidentiality or integrity, its impact on service availability is high.

The primary remediation for this vulnerability is updating the Excelize dependency within the application module. Users should target versions containing the official patch merged in PR #2438, or explicitly pin their module configurations to the fixed commit hash:

go get github.com/xuri/excelize/v2@01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23

If updating the library is not immediately possible, applications should implement strict execution timeouts for document parsing tasks. Using Go contexts with strict deadlines guarantees that any parsing operations that exceed reasonable execution boundaries will be terminated forcefully:

ctx, cancel := context.WithTimeout(context.Background(), 10 * time.Second)
defer cancel()
// Implement context check within processing logic

Additional mitigation steps include enforcing payload size limitations at the API gateway layer to prevent extremely large files from reaching backend parsers. Isolating parsing engines in resource-constrained containers (e.g., configuring CPU limits in Kubernetes or Docker) ensures that resource starvation is isolated and does not compromise critical infrastructure.