Memory Exhaustion in Excelize via Malicious XLSX

Executive Summary

CVE-2026-54063 is a Denial-of-Service vulnerability in the Go library github.com/xuri/excelize/v2, which is used for reading and writing Microsoft Excel spreadsheets.

The issue occurs in the checkSheet() function that processes the <row r="N"> XML attribute in XLSX files without validating the row index against Excel's maximum row limit of 1,048,576.

An attacker can craft malicious XLSX files with specially set row values that cause either a large memory allocation (~16 GB) leading to an out-of-memory kill, or a runtime panic due to out-of-bounds slice access.

This vulnerability is triggered when a Go application using excelize opens an attacker-supplied XLSX file and calls functions like GetCellValue, which internally invoke checkSheet().

No authentication or user interaction is required beyond uploading the malicious file.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability described is a denial-of-service (DoS) issue that can cause application crashes or out-of-memory conditions when processing specially crafted XLSX files. It does not directly involve unauthorized access, data leakage, or modification of sensitive information.

However, services affected by this vulnerability that handle sensitive data subject to regulations like GDPR or HIPAA could face availability issues due to service disruption. Such disruptions might impact compliance requirements related to system availability and reliability.

There is no indication from the provided information that this vulnerability leads to confidentiality or integrity breaches, which are typically critical for compliance with these standards.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause denial-of-service conditions in applications using the excelize library to process XLSX files.

• An attacker can crash the application by forcing it to allocate excessive memory (~16 GB), leading to an out-of-memory process kill.
• Alternatively, the attacker can trigger a runtime panic due to out-of-bounds slice indexing, causing the application to crash.

Any service that opens attacker-supplied XLSX files and calls GetCellValue or similar functions is vulnerable, including web services with XLSX upload endpoints, command-line tools, and batch jobs.

Because no authentication is required, attackers can easily exploit this by submitting malicious XLSX files.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring for crashes or out-of-memory (OOM) events in applications using the excelize Go library when processing XLSX files.

Specifically, detection involves identifying if any service or application that opens XLSX files and calls functions like GetCellValue is crashing or being killed due to excessive memory allocation or runtime panics.

Since the vulnerability is triggered by specially crafted XLSX files with malicious <row r="N"> XML attributes, you can detect suspicious XLSX files by inspecting their XML content for row attributes with values exceeding Excel's maximum row limit (1,048,576) or negative values.

Suggested commands include extracting and inspecting the sheet XML files inside XLSX archives (which are ZIP files) using unzip and grep, for example:

• unzip -p suspicious_file.xlsx xl/worksheets/sheet1.xml | grep -oP '<row r="\K[^"]+' | awk '{if ($1 > 1048576 || $1 < 1) print $1}'

Additionally, monitoring application logs for runtime panics or OOM kills related to excelize usage can help detect exploitation attempts.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade the excelize Go library to version 2.11.0 or later, where this vulnerability is fixed.

Until the upgrade can be applied, avoid processing untrusted or attacker-supplied XLSX files with vulnerable versions of excelize.

If processing untrusted XLSX files is necessary, implement input validation to reject XLSX files containing row attributes with values outside the valid Excel row range (1 to 1,048,576).

Additionally, consider running the application in a restricted environment with resource limits to mitigate the impact of potential out-of-memory conditions.

Useful 0 Not Useful 0