EUVD-2026-94551
GHSA-8mcq-6wmr-jrjv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft XLSX row with higher-column cell before final lower-column cell
-
ExploitVictim service reads sheet via non-streaming API (GetCellValue)
-
ExecutionSlice index exceeds length derived from final cell
-
ImpactUnrecovered panic terminates process
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, write limits
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the application to read an attacker-controlled .xlsx file containing a row whose cells are out of column order - specifically a higher-column cell (e.g. D1) placed before the lower-column final cell (e.g. B1) - and to parse it with a non-streaming worksheet API such as GetCellValue/GetRows that routes through workSheetReader and checkRow. Limiting factors: exploitation needs user/application interaction to load the crafted file (UI:R), impact is limited to a process crash with no data exposure or code execution, applications using the streaming Rows() reader may avoid the vulnerable checkRow path, and only excelize versions 2.0.0 through 2.11.0 are affected. |
| Impact | This is a medium-severity denial-of-service issue, not a high-priority emergency. The CVSS 6.5 is driven entirely by availability (A:H) with no confidentiality or integrity impact (C:N/I:N) - the worst outcome is an unrecovered panic that crashes the process. The vector is favorable to an attacker in theory (AV:N/AC:L/PR:N) but is tempered by UI:R: the victim application must actually load and read a crafted .xlsx file via a non-streaming API, so this is not wormable or automatable in the SSVC sense (exploitation=none, automatable=no, technical impact=partial/DoS-only). No KEV listing and no EPSS score were provided, and no public exploit exists beyond the reproducing test case in the fix PR - all signals point to low real-world urgency. The one genuinely elevated signal is patch availability: the description states 'No fixed version is available as of this review' even though PR #2376 contains the fix and its reproducing test, so there is a patch-readiness gap worth tracking. Real priority is conditional: elevated only for services that parse untrusted/user-uploaded spreadsheets through excelize's non-streaming worksheet APIs; otherwise low. |
| Exploit ScenarioDerived | An attacker uploads a malicious .xlsx file to a Go service that uses excelize to read spreadsheet contents. The file contains a row where a higher-column cell (e.g. D1) is placed before the lower-column final cell (e.g. B1); when the service calls a non-streaming API such as GetCellValue, checkRow sizes the target slice from the final cell and the earlier cell's larger column index overruns it, triggering an unrecovered panic that terminates the process. No public exploit exists, but PR #2376 includes a test that reproduces the crash with a descending-column row. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
A crafted Excel (.xlsx) file can crash any Go application that parses it with Excelize 2.0.0 through 2.11.0 using a non-streaming worksheet API, resulting in an unrecovered panic that terminates the process. The bug occurs when a row lists a higher-column cell (e.g. D1) before a lower-column final cell (e.g. B1): checkRow sizes its backing cell slice from the last cell in document order, so the earlier cell's column index falls outside the slice and triggers an out-of-bounds access. Exploitation requires the victim or application to load the malicious workbook (UI:R), impact is limited to availability with no data disclosure or code execution, and no public exploit was identified at time of analysis; an upstream fix is available as a PR/commit but a released patched version is not independently confirmed.
RemediationAI
No vendor-released patch was identified at time of analysis: the CVE record states no fixed version is available, so the most specific status is that an upstream fix exists only as a PR/commit (PR #2376, commit 46a5eb289448e40fbc7d3294589b03861fb822f0) and a released tagged version is not independently confirmed - operators should track https://github.com/qax-os/excelize/security/advisories/GHSA-8mcq-6wmr-jrjv and adopt the patched commit or the next tagged release as soon as it is published. Until then, practical compensating controls are: (1) switch untrusted-file parsing to the streaming Rows() reader, which bypasses the workSheetReader/checkRow path at the cost of losing the convenience of random cell access and some worksheet metadata features; (2) wrap all xlsx parsing in a deferred recover() in the same goroutine, or run it in a separate subprocess/worker pool, so a panic is contained and kills only the worker rather than the host process - this contains the crash but does not eliminate it and adds operational overhead; (3) gate ingestion with input validation or a pre-parse reserialization step that rejects or rewrites rows whose cell r references are not in ascending column order, accepting the extra CPU cost and the risk of false positives on legitimate but unusual files; and (4) treat untrusted workbooks as hostile input by imposing file-size/row-count limits and sandboxing the parsing service so a crash cannot cascade into a broader outage.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Excelize is a pure-Go library for reading and writing Office Open XML spreadsheets. Internally, rows.go's checkRow normalizes each parsed row so that cells are re-scattered into a slice indexed by their explicit column reference (the r attribute, e.g. A1, D1). In vulnerable versions the slice length was derived solely from the column of the last cell appearing in XML document order, and cells were then re-placed using their parsed column index. Because the OOXML schema does not require cells to be listed in ascending column order, a row such as <c r="D1"> followed by <c r="B1"> yields a slice sized for column B (2) while the D cell's index (4) is written/read beyond that length, an out-of-bounds memory access classified as CWE-787 (Out-of-bounds Write). The upstream patch (PR #2376) rewrites checkRow to compute both the cell count and the maximum column encountered while iterating, sizing the slice against the true maximum column rather than the document-order final cell, and adds a regression test that feeds a descending-order row (D1 then B1) through GetCellValue to assert a correctly sized 4-element row. The flaw is reachable through the non-streaming read path (GetCellValue, GetRows, workSheetReader -> checkRow), whereas the streaming Rows() reader may avoid it.
Know when Excelize gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Crafted file is trivial to build (AC:L) and needs no privileges (PR:N), but the app must read it (UI:R); only a process-crashing panic results, so C:N/I:N/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
DescriptionCVE.org
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.0.0 to 2.11.0, checkRow sizes its target cell slice from the last cell in XML document order and then re-scatters every cell by its explicit column reference. GetCellValue reaches workSheetReader and checkRow, where targetList is too short for an earlier out-of-order cell. When a crafted row places a higher-column cell before a lower-column final cell and a non-streaming worksheet API reads the sheet, the earlier cell's column index exceeds the slice length derived from the final cell, allowing an attacker to cause an unrecovered panic and terminate the process. No fixed version is available as of this review.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Denial of service in the Excelize Go library (github.com/xuri/excelize/v2, a.k.a. qax-os/excelize) before 2.11.0 allows
Denial of service in the Excelize Go library (versions 2.1.0 through 2.11.0) allows an attacker-controlled spreadsheet t
Uncontrolled memory and CPU consumption in Excelize (qax-os/excelize), the widely used Go library for reading and writin
Denial of service in Excelize 2.9.0 through 2.11.0 allows a crafted spreadsheet to panic and terminate a Go process that
Go slice-bounds panic in the Excelize spreadsheet library versions 2.8.1 through 2.11.0 lets a crafted .xlsx workbook cr
Denial of service in the Excelize Go library (versions 2.3.1 through 2.11.0) allows unauthenticated remote attackers to
Denial of service in the Excelize Go spreadsheet library (github.com/xuri/excelize/v2 2.0.0-2.11.0 and github.com/xuri/e
Uncontrolled recursion in the Excelize Go library (versions 2.8.1 through 2.11.0) allows a fatal Go stack overflow that
Denial of service in Excelize versions 2.3.1 through 2.11.0 allows unauthenticated remote attackers to terminate the cal
Memory exhaustion and runtime panic in the Excelize Go library (versions 2.3.1 through 2.11.0) let unauthenticated remot
Resource exhaustion in the Excelize Go library (versions 2.1.0 through 2.11.0) lets a crafted .xlsx workbook drive exces
Panic-triggering denial of service in the Excelize Go library (all versions prior to 2.11.0) allows any actor who can su
Exploit-DB