CVE-2026-59162: Excelize Denial-of-Service via Malicious XLSX File Parsing

Technical summary

Excelize versions before 2.11.0 fail to properly validate shared-string cell indices before array access. When parsing shared-string references, the library uses strconv.Atoi to convert index values and only checks the upper bound before indexing the sharedStrings slice. This leaves the lower bound unvalidated, allowing negative indices (such as -1) to bypass the bounds check and trigger an out-of-bounds array access. In Go, negative array indices do not wrap around; instead, they cause a panic when the slice is accessed with an invalid index. Functions like GetCellValue and GetRows are vulnerable, as they invoke this parsing logic when processing cell data from the shared strings table.

Business impact

Applications relying on Excelize to process user-supplied or untrusted XLSX files are vulnerable to denial-of-service attacks. An attacker can upload or distribute a malicious Excel file that crashes any service using Excelize to read it, disrupting availability and potentially affecting data pipelines, reporting systems, or file processing workflows. For SaaS platforms or internal tools that accept Excel uploads, this creates a trivial attack vector requiring no authentication or special privileges.

Affected systems

Excelize versions prior to 2.11.0 are affected. Any application, service, or tool built in Go that embeds the Excelize library and processes XLSX files from untrusted sources is at risk. This includes web applications accepting file uploads, data integration platforms, and batch processing systems that consume Excel documents.

Exploitability

Exploitation requires only the ability to provide a malicious XLSX file to an application using vulnerable Excelize. No network interaction, authentication, or user interaction beyond opening the file is needed. The attack surface is high for any service that accepts Excel uploads or processes spreadsheets from external sources. The barrier to entry is extremely low; crafting such a file requires only basic knowledge of the XLSX format or use of existing spreadsheet tools.

Remediation

Update Excelize to version 2.11.0 or later. This version implements proper bounds checking for both upper and lower indices before accessing the shared strings array. Organizations should identify all applications and services using Excelize and prioritize patching in environments that process untrusted Excel files.

Patch guidance

Verify your Go module dependencies to confirm the current version of Excelize in use. Update the dependency to excelize v2.11.0 or later by running 'go get -u github.com/xuri/excelize/v2@latest' (or the appropriate versioned import path for your codebase). Run your application's test suite to ensure compatibility with the patched version. If you maintain a vendored copy of Excelize, replace it with the patched version from the official repository. Recompile and redeploy all affected binaries.

Detection guidance

Monitor for unexpected panics or crashes in applications using Excelize, particularly when processing XLSX files from external sources. Enable logging of file processing errors and correlation of errors with specific files or users. In development environments, add fuzzing or property-based tests that generate XLSX files with extreme or invalid cell index values. Review application logs for repeated failure patterns when handling spreadsheet files. Consider implementing a pre-upload file validation layer that sanitizes or checks XLSX structure before passing it to Excelize.

Why prioritize this

Although this is a denial-of-service vulnerability with no confidentiality or integrity impact, it carries a HIGH CVSS score (7.5) due to its network accessibility, lack of privileges required, and guaranteed availability impact. Organizations processing user-supplied Excel files should prioritize patching to maintain service reliability. The low exploitation barrier and ease of weaponization in multi-tenant environments elevate business risk even though technical severity is limited to availability.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a network-accessible denial-of-service condition with no authentication required and no user interaction needed. The vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates high availability impact but no data confidentiality or integrity compromise. The score appropriately captures the operational disruption risk while acknowledging the absence of data breach or system compromise potential. Organizations should not dismiss this as low-risk; reliable availability is often as critical as data protection.

Frequently asked questions