GHSA-FX5J-QCQG-GRPF
Vulnerability from github – Published: 2026-09-10 15:08 – Updated: 2026-09-10 15:08Negative 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 releasev2.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:
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 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:
== negative shared string GetCellValue ==
elapsed=0s alloc_delta=0MB
PANIC: runtime.boundsError runtime error: index out of range [-1]
Calling GetRows("Sheet1") on the same workbook also panics:
== negative shared string GetRows ==
elapsed=0s alloc_delta=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:
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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/xuri/excelize/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/xuri/excelize"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59162"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:08:53Z",
"nvd_published_at": "2026-07-10T17:17:02Z",
"severity": "MODERATE"
},
"details": "# Negative shared-string index causes panic in GetCellValue and GetRows\n\n## Summary\n\nExcelize 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 `\u003cv\u003e-1\u003c/v\u003e`, the parsed index is negative. The upper-bound check still passes (`len(sharedStrings) \u003e -1`), and Excelize indexes `sharedStrings[-1]`, causing a runtime panic.\n\nThis 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.\n\n## Affected package\n\n- Package: `github.com/xuri/excelize/v2`\n- Tested affected versions: current default branch at `1213a8bd7c5ab360554603ac5c995ccaf6eb4314`, and release `v2.10.1`\n- Fixed version: none known at the time of this report\n\n## Impact\n\nAn 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.\n\n## Root cause\n\nFor 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:\n\n```go\nxlsxSI, _ := strconv.Atoi(strings.TrimSpace(c.V))\nif len(d.SI) \u003e xlsxSI {\n return d.SI[xlsxSI].String(), nil\n}\n```\n\nFor `xlsxSI == -1`, `len(d.SI) \u003e -1` is true, so the code proceeds to index `d.SI[-1]` and panics.\n\n## Minimal worksheet payload\n\n```xml\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003cworksheet xmlns=\"http://schemas.openxmlformats.org/spreadsheetml/2006/main\"\u003e\n \u003csheetData\u003e\n \u003crow r=\"1\"\u003e\u003cc r=\"A1\" t=\"s\"\u003e\u003cv\u003e-1\u003c/v\u003e\u003c/c\u003e\u003c/row\u003e\n \u003c/sheetData\u003e\n\u003c/worksheet\u003e\n```\n\nThe workbook also contains a normal `sharedStrings.xml` with one string (`ok`), so the failure is specifically due to accepting a negative index.\n\n## Reproduction\n\nCalling `GetCellValue(\"Sheet1\", \"A1\")` on the workbook panics:\n\n```text\n== negative shared string GetCellValue ==\nelapsed=0s alloc_delta=0MB\nPANIC: runtime.boundsError runtime error: index out of range [-1]\n```\n\nCalling `GetRows(\"Sheet1\")` on the same workbook also panics:\n\n```text\n== negative shared string GetRows ==\nelapsed=0s alloc_delta=0MB\nPANIC: runtime.boundsError runtime error: index out of range [-1]\n```\n\nThe same results were observed on current default branch commit `1213a8bd7c5ab360554603ac5c995ccaf6eb4314` and on release `v2.10.1`.\n\n## Expected behavior\n\nMalformed shared-string indices should be rejected or treated as missing/invalid string references without panicking.\n\n## Suggested remediation\n\nCheck both lower and upper bounds before indexing the shared string table. For example:\n\n```go\nif xlsxSI \u003e= 0 \u0026\u0026 xlsxSI \u003c len(d.SI) {\n return d.SI[xlsxSI].String(), nil\n}\n```\n\nAdd regression tests for `GetCellValue()` and `GetRows()` on `t=\"s\"` cells whose `\u003cv\u003e` value is negative.",
"id": "GHSA-fx5j-qcqg-grpf",
"modified": "2026-09-10T15:08:53Z",
"published": "2026-09-10T15:08:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/security/advisories/GHSA-fx5j-qcqg-grpf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59162"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/pull/2331"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/commit/93f0b3caed37f21ef5079e3259c6c21dcfe68453"
},
{
"type": "PACKAGE",
"url": "https://github.com/qax-os/excelize"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/releases/tag/v2.11.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Excelize: Negative shared-string index causes panic in GetCellValue and GetRows"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.