EUVD-2026-94554
GHSA-fq3v-74gv-27gm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDeliver crafted XLSX with oversized col max attribute
-
ExploitApplication loads file and calls SetColWidth reaching flatCols
-
ImpactDeep-copy/append per column exhausts memory, triggering OOM/DoS
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Memory allocation limits
|
| Exploitation Conditions | Requires the application to (1) parse an attacker-controlled .xlsx file in which a worksheet |
| Impact | This is a denial-of-service (resource exhaustion, CWE-789) vulnerability in the Excelize Go library, not a priority emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) correctly scopes impact to availability only (VA:H) with zero confidentiality/integrity impact - so despite the 'Information Disclosure' tag in the input, no data exposure occurs; that tag is contradicted by the vector and should be disregarded. Exploitation is unauthenticated (PR:N) but is gated by passive user interaction (UI:P): the victim application must load an attacker-supplied spreadsheet AND subsequently invoke a column-mutating API (e.g., SetColWidth). No EPSS score was provided and the CVE is not on CISA KEV, so there is no evidence of active or widespread exploitation; exploitation status is 'no public exploit identified at time of analysis,' though the upstream PR #2370 includes a regression test that reproduces the trigger condition. The practical risk is moderate: easy to trigger where untrusted .xlsx files are processed, but limited to crash/OOM rather than code execution or data loss. Note the key gap - no fixed release version exists as of this analysis (only an unmerged/merged patch commit), so remediation currently requires pinning to the patched commit or adding input validation. |
| Exploit ScenarioDerived | An attacker uploads or emails a crafted .xlsx file whose worksheet column definition specifies an oversized |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Resource exhaustion in the Excelize Go library (versions 2.1.0 through 2.11.0) lets a crafted .xlsx workbook drive excessive CPU and memory consumption - up to process OOM - when an application loads the file and later invokes a column-mutating API such as SetColWidth. The root cause is a missing bounds check in flatCols, which iterates from an attacker-controlled column minimum to an attacker-controlled maximum and performs a deep copy plus append for every declared column number instead of clamping to the spreadsheet's 16,384-column limit. Exploitation requires a victim or service to parse the malicious workbook (UI:P) and then perform a column operation on it; no authentication to the library is required (PR:N), no public exploit code has been identified at time of analysis, and no fixed release is available - although an upstream fix exists as a pull request and commit. CVSS 4.0 base score is 7.1 with availability-only impact (VC:N/VI:N/VA:H); the impact is denial of service, not confidentiality or integrity loss.
RemediationAI
No vendor-released patch version is identified at time of analysis, but the upstream fix is available as pull request 2370 (commit a54c578af309fa81f448143ed2b7a91192cc58a7), which clamps the iteration bounds in setColWidth and flatCols to max(MinColumns, col.Min) and min(MaxColumns, col.Max); teams that build Go binaries should vendor or pin to that commit (or a later tagged release once published) and confirm the CPE range no longer matches. Until then, apply targeted compensating controls in order of effectiveness: reject or pre-sanitize uploaded workbooks whose worksheet <col> elements declare Min/Max outside the legal 1-16384 range before they reach the library - a strict schema check on the cols block eliminates the attack with negligible false positives for legitimate files; enforce hard resource ceilings on the parsing process (container memory limits, GOMEMLIMIT, cgroup OOM handling, and per-request context deadlines) so an oversized worksheet aborts instead of taking down the host - this bounds blast radius but does not prevent the CPU spin itself; and avoid exposing column-mutating APIs such as SetColWidth on attacker-supplied content, deferring any such mutation to workbooks the service generated itself. Large-file upload caps are only a weak partial mitigation, since the malicious <col max> attribute is tiny and the amplification happens at parse/mutate time rather than at read time. Monitor for high-CPU or OOM-kill events during xlsx ingestion as a detection signal, and track the advisory at https://github.com/qax-os/excelize/security/advisories/GHSA-fq3v-74gv-27gm for the eventual patched release.
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 Microsoft Excel (OOXML/XLSX) files, published as github.com/xuri/excelize/v2 and maintained under the qax-os organization; CPE cpe:2.3:a:qax-os:excelize:*:*:*:*:*:*:*:* tracks the package, and the advisory GHSA-fq3v-74gv-27gm scopes the affected range to 2.1.0-2.11.0. In OOXML, column width and formatting metadata live in the worksheet's <cols> element, where each <col> entry carries Min and Max attributes defining the inclusive column index range it applies to; the library's internal xlsxCol type stores these as integers, and MaxColumns (16,384, i.e. column XFD) is the hard worksheet limit. The flatCols helper materializes a single xlsxCol entry covering an arbitrary Min-Max range into one entry per physical column, deep-copying and appending for each iteration. Because bounds were never enforced against MinColumns/MaxColumns, a worksheet supplying an oversized <col max="N"> value causes flatCols to allocate and append N entries when a column mutator - SetColWidth reaches this path, as do related mutators - is called, with the loop count chosen directly by the attacker. This is CWE-789 (Memory Allocation with Excessive Size Value): the allocation size derives from untrusted input with no upper bound, converting a small input file into unbounded heap growth and CPU spin. Note that the supplied tag metadata labels this "Information Disclosure," which is inconsistent with the actual vector and code path - the impact is purely availability (VC:N/VI:N/VA:H), and there is no evidence of data exposure. The upstream fix changes the loop bounds in both setColWidth and flatCols from a raw col.Min→col.Max iteration to max(MinColumns, col.Min)→min(MaxColumns, col.Max), and adds a regression test that injects a col entry with Min 0 and Max MaxColumns+1 and asserts the materialized slice is capped at MaxColumns.
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
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Crafted file is delivered over the network (AV:N) but a user/app must load and mutate it (UI:R); no auth to the library (PR:N); impact is availability-only OOM (A:H, C/I:N).
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.1.0 to 2.11.0, flatCols expands file-loaded column ranges without validating Min and Max against the worksheet column limit. SetColWidth reaches flatCols, which expands xlsxCol.Min through xlsxCol.Max without enforcing MaxColumns. When a crafted worksheet supplies an oversized col max attribute and the application invokes a column mutator, flatCols performs a deep copy and append for every attacker-selected column number, allowing an attacker to consume excessive CPU and memory or trigger OOM. No fixed version is available as of this review.
Technical POC Analysis
CWE-789 (Memory Allocation with Excessive Size Value).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Any application built on the Excelize Go library (versions 2.1.0 through 2.11.0) can be forced into memory exhaustion and process termination when it opens a maliciously crafted .xlsx file and subsequently performs a column operation such as SetColWidth. Because Excelize is an embedded open-source dependency rather than a standalone product, exposure is likely invisible on asset inventories, and internal reporting, import, and document-processing services that accept spreadsheets from users or external parties are the most probable points of failure. Leadership should care because no vendor-released fix exists yet and the failure mode is an availability outage, not a data breach - remediation depends on engineering controls and service isolation rather than a simple patch-and-close.
No vendor-released patch identified at time of analysis; upstream fix exists only as a pull request and commit. Interim mitigations: restrict .xlsx ingestion to trusted sources; reject or clamp workbooks declaring columns beyond 16,384; enforce container memory/CPU limits, parse timeouts, and restart-on-OOM supervision; run parsing in an isolated, short-lived sandboxed worker; vendor or fork the library to apply the bounds check in flatCols; monitor for OOM kills and CPU saturation. Note that exploitation is unauthenticated at the library level (PR:N) but requires the victim application to parse the crafted workbook and then invoke a column-mutating API.
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
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
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
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