EUVD-2026-94547
GHSA-c85p-xxjj-2r75
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessUpload crafted XLSX to Go service
-
DeliveryWorksheet uses overflowing column name
-
Exploitint64 column value wraps to zero/negative
-
ExecutionNegative slice index in row normalization panics
-
ImpactCalling process terminates (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Integer overflow checks
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable only when an application built on vulnerable excelize (v2 2.0.0-2.11.0 or v1 1.1.0-1.4.1) opens or normalizes an attacker-controlled spreadsheet whose worksheet contains an overflowing bijective base-26 column name (e.g., VGWQHXLSDVIKWV), triggering the checkSheetR0 or xlsxWorksheet.checkRow normalization paths. Limiting factors: the host application must accept untrusted/externally supplied spreadsheet files and invoke the parsing/normalization code path; there is no authentication or user interaction required by the library itself, but reachability depends entirely on the embedding application exposing file input. No vendor-fixed version is available, so upgrading is not yet a mitigation - input validation or rejecting untrusted files is the only control. |
| Impact | This is a moderate-severity denial-of-service issue, not a high-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) reflects an availability-only impact with no confidentiality or integrity consequence - the root cause (CWE-190 integer overflow in ColumnNameToNumber) produces a negative slice index and a Go panic that terminates the calling process. The 'network' attack vector is contingent: excelize is a Go library, so AV:N only holds if the embedding application accepts and parses attacker-supplied spreadsheets (e.g., a file-upload endpoint); in a batch tool processing trusted files the practical reachability is far lower. No KEV listing and no EPSS score were provided in the input, and no public exploit code is referenced - the advisory and fix PR describe the exact trigger string (VGWQHXLSDVIKWV) but a trigger string is not weaponized exploit code. The most important operational fact is that NO fixed version is available as of this review, so the only mitigation is validating/rejecting untrusted spreadsheet input or restricting who can submit files. Net: real but bounded - a crash/availability bug worth patching when a fix ships, not a remote code execution or data-exposure event. |
| Exploit ScenarioDerived | An attacker uploads a crafted .xlsx file to a Go web service that uses excelize to open and normalize worksheets. The worksheet references an overflowing bijective base-26 column name such as VGWQHXLSDVIKWV, which wraps to zero and then to a negative slice index inside checkSheetR0/checkRow during normalization, panicking and crashing the worker process. No public exploit code is referenced, though the advisory discloses the precise triggering column name. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Denial of service in the Excelize Go spreadsheet library (github.com/xuri/excelize/v2 2.0.0-2.11.0 and github.com/xuri/excelize 1.1.0-1.4.1) lets an unauthenticated remote attacker terminate the calling process by supplying a crafted workbook. The ColumnNameToNumber function converts bijective base-26 column names into int64 without overflow detection, so an over-long name such as VGWQHXLSDVIKWV wraps to zero and is later used as a slice index by checkSheetR0 and xlsxWorksheet.checkRow, producing a negative index panic during worksheet normalization. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5), meaning availability-only impact; there is no evidence of confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, though the upstream fix commit and PR are public. This is a moderate-severity denial-of-service condition rather than a high-priority emergency, and it is only reachable when an application built on the vulnerable versions parses an untrusted spreadsheet.
RemediationAI
No vendor-released patched version was identified at time of analysis, so upgrading is not yet a confirmed mitigation: the CVE record explicitly states no fixed version is available as of this review, and the upstream remedy exists only as the pull request and commit referenced above (https://github.com/qax-os/excelize/pull/2394, https://github.com/qax-os/excelize/commit/696050fbf14e74e96a58eef2b16aaf72f381a6a8), which moves the MaxColumns bounds check into the accumulation loop of ColumnNameToNumber and routes SplitCellName through that function - treat this as an unconfirmed released fix and verify a tagged release before relying on it. If you can vendor or replace the module, applying that commit or pinning to a release that contains it is the cleanest control. Until then, the practical steps are: reject or quarantine untrusted workbooks at the API boundary (accept only files from trusted sources, cap upload size, and enforce a strict allowlist of expected column-name patterns such as 1-3 uppercase letters before parsing); run the excelize parse in an isolated worker with a deferred recover() so a panic unwinds a single request or job instead of the host process, accepting that this contains but does not eliminate the DoS and does not protect code paths that do not wrap parsing in recover; and execute parsing in a separate short-lived subprocess or sandbox with restart-on-crash and timeouts, which costs latency and complexity but bounds blast radius. Because the assessed impact is availability-only (C:N/I:N/A:H), prioritize these controls behind higher-severity findings and plan to upgrade once a fixed tagged release is confirmed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 4 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
Excel column labels use a bijective base-26 notation (A=1 … Z=26, AA=27, AB=28, …), which Excelize decodes in lib.go's ColumnNameToNumber by repeatedly multiplying an int64 accumulator by 26 and adding the digit value. The routine accepts arbitrarily long alphabetic strings, so a sufficiently long name overflows the int64 and, for specific inputs such as VGWQHXLSDVIKWV, wraps to a value of zero without returning an error; the fix's regression test uses CRPXNLSKVLJFHH, described as the column name corresponding to math.MaxInt64+1. The root cause class is CWE-190 (Integer Overflow or Wraparound): the bounds check against the library's MaxColumns constant (16384, the spreadsheet column limit) was applied only after the accumulation loop, and the separate SplitCellName routine normalized characters itself instead of delegating to ColumnNameToNumber, so the overflow path was reachable. Because the wrapped column value flows into indexing logic used by checkSheetR0 and xlsxWorksheet.checkRow during worksheet normalization, a negative index can be computed and a Go runtime panic occurs, unwinding and terminating the calling process unless the caller recovers. Affected components are tracked as CPE cpe:2.3:a:qax-os:excelize:*:*:*:*:*:*:*:* (the qax-os/xuri Excelize Go module). No memory-safety impact (Go is memory-safe) and no confidentiality or integrity impact were assessed - the effect is purely a crash/panic.
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:N/S:U/C:N/I:N/A:H
A crafted spreadsheet reliably triggers a process-terminating panic with no privileges or interaction when reachable via file input, and impact is availability-only (no C/I).
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 in github.com/xuri/excelize/v2 and from 1.1.0 to 1.4.1 in github.com/xuri/excelize, ColumnNameToNumber accumulates a bijective base-26 value in int64 without detecting overflow, allowing an invalid long column name to wrap to zero with no error. ColumnNameToNumber accepts the overflowing name VGWQHXLSDVIKWV, after which checkSheetR0 and xlsxWorksheet.checkRow use the wrapped column value as an index. When a crafted worksheet uses an overflowing column name in a row normalized by checkSheetR0 or checkRow, the wrapped zero column becomes a negative slice index during worksheet normalization, allowing an attacker to panic and terminate the calling process. No fixed version is available as of this review.
Technical POC Analysis
Integer overflow / wraparound of a signed 64-bit accumulator (CWE-190; the GHSA record itself lists no CWE, the CVE record supplied with this review assigns CWE-190).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
The Excelize Go library (versions 2.0.0-2.11.0 and 1.1.0-1.4.1) contains a denial-of-service vulnerability (CVE-2026-107217) that allows an unauthenticated remote attacker to terminate the calling process by supplying a crafted workbook. Organizations using applications built on these versions may face service disruptions if they process untrusted spreadsheets, impacting availability of business-critical file-processing workflows. No public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis, though an upstream fix commit and PR are public.
Implement strict input validation to reject column names exceeding expected length or malformed workbook structures; restrict processing of untrusted workbooks to isolated, resource-limited containers with automatic restarts; monitor for process crashes and abnormal terminations; consider pre-processing spreadsheet input with a sanitizer before passing to Excelize; and apply the upstream fix commit as a temporary custom build if feasible.
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
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Integer overflow occurs when an arithmetic operation produces a result that exceeds the maximum value a given integer type can store.
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
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-
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
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