GHSA-fx5j-qcqg-grpf: Go/github.com/xuri/excelize vulnerability

Published Sep 10, 2026
·
Updated

Negative shared-string index causes panic in GetCellValue and GetRows

Summary

Excelize parses shared-string cell values with strconv.Atoi and checks only the upper bound before indexing the shared string slice. If an XLSX file contains a shared-string cell with <v>-1</v>, the parsed index is negative. The upper-bound check still passes (len(sharedStrings) > -1), and Excelize indexes sharedStrings[-1], causing a runtime panic.

This was reproduced on the current default branch commit 1213a8bd7c5ab360554603ac5c995ccaf6eb4314 and the latest release tag v2.10.1 (5ad5ab3af0054c55bdce09f1530085600e9f2e45). The issue is independent from the row-bound allocation report, so I am reporting it separately.

Affected package

- Package: github.com/xuri/excelize/v2 - Tested affected versions: current default branch at 1213a8bd7c5ab360554603ac5c995ccaf6eb4314, and release v2.10.1 - Fixed version: none known at the time of this report

Impact

An attacker who can provide an XLSX file to an application using Excelize can trigger a process panic when the application reads the malicious cell through common APIs such as GetCellValue or GetRows. In services that parse untrusted spreadsheets without a panic recovery boundary, this can cause denial of service.

Root cause

For shared-string cells (t="s"), xlsxC.getValueFrom() parses the cell value as a shared-string index and only checks whether the index is below len(d.SI) before indexing:

go xlsxSI, := strconv.Atoi(strings.TrimSpace(c.V)) if len(d.SI) > xlsxSI { return d.SI[xlsxSI].String(), nil }

For xlsxSI == -1, len(d.SI) > -1 is true, so the code proceeds to index d.SI[-1] and panics.

Minimal worksheet payload

xml <?xml version="1.0" encoding="UTF-8"?> <worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"> <sheetData> <row r="1"><c r="A1" t="s"><v>-1</v></c></row> </sheetData> </worksheet>

The workbook also contains a normal sharedStrings.xml with one string (ok), so the failure is specifically due to accepting a negative index.

Reproduction

Calling GetCellValue("Sheet1", "A1") on the workbook panics:

text == negative shared string GetCellValue == elapsed=0s allocdelta=0MB PANIC: runtime.boundsError runtime error: index out of range [-1]

Calling GetRows("Sheet1") on the same workbook also panics:

text == negative shared string GetRows == elapsed=0s allocdelta=0MB PANIC: runtime.boundsError runtime error: index out of range [-1]

The same results were observed on current default branch commit 1213a8bd7c5ab360554603ac5c995ccaf6eb4314 and on release v2.10.1.

Expected behavior

Malformed shared-string indices should be rejected or treated as missing/invalid string references without panicking.

Suggested remediation

Check both lower and upper bounds before indexing the shared string table. For example:

go if xlsxSI >= 0 && xlsxSI < len(d.SI) { return d.SI[xlsxSI].String(), nil }

Add regression tests for GetCellValue() and GetRows() on t="s" cells whose <v> value is negative.

Affected Software

2 affected componentsFixes available
go/github.com/xuri/excelize<=1.4.0
go/github.com/xuri/excelize/v2<2.11.0
2.11.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/xuri/excelize/v2 to a version that resolves this vulnerability.

    Fixed in 2.11.0
  2. Upgrade

    Upgrade github.com/xuri/excelize/v2 to a version that resolves this vulnerability.

    Fixed in v2.10.1
  3. Configuration

    Implement/ensure bounds checks for shared-string (`t="s"`) cell values: parse `<v>` into `xlsxSI` (via `strconv.Atoi`), then require `xlsxSI >= 0 && xlsxSI < len(d.SI)` before indexing `d.SI[xlsxSI]`. If `xlsxSI` is negative (e.g., `<v>-1</v>`), return an error or treat the value as missing/invalid rather than panicking.

    github.com/xuri/excelize/v2 shared-string index bounds check in getValueFrom/GetCellValue/GetRows (t="s") = Reject negative shared-string indices (xlsxSI < 0) and treat as invalid/missing instead of indexing d.SI[xlsxSI]

Event History

Sep 10, 2026
Advisory Published
via GitHub·03:08 PM
Data Sourced
via GitHub·03:08 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which applications are realistically exposed to this issue?

Applications using github.com/xuri/excelize/v2 that accept XLSX files from an attacker-controlled or otherwise untrusted source are exposed when they read affected shared-string cells. Services that parse uploaded spreadsheets are particularly at risk because a panic can disrupt the process.

2

What must an attacker provide to trigger the failure?

The attacker needs to provide an XLSX file containing a shared-string cell whose value is a negative index, such as <v>-1</v>. The application must then read that cell through APIs such as GetCellValue or GetRows.

3

Which versions are known to be affected, and is a fixed release available?

The issue was reproduced in v2.10.1 and on the tested default-branch commit 1213a8bd7c5ab360554603ac5c995ccaf6eb4314. No fixed version was known at the time of the report.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203