CVE-2026-107211 in excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.8.1 to 2.11.0, separately parsed pivot-table field indices are used to index the pivot-cache field-name slice without bounds checks. extractPivotTableFields uses getPivotCacheFieldsName output while processing GetPivotTables and trusts the dataField fld attribute as an index. When a crafted workbook supplies a pivot-field count mismatch or an out-of-range dataField fld value before GetPivotTables is called, the unchecked index causes a Go slice-bounds panic that escapes the library, allowing an attacker to crash the process or request worker. No fixed version is available as of this review.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Excelize versions 2.8.1 through 2.11.0 represents a critical failure in input validation and bounds checking within the Go language library responsible for processing Microsoft Excel spreadsheets. This specific flaw manifests during the parsing of pivot table structures, where the application logic relies on indices extracted from the workbook data to access internal slices without verifying that these indices fall within acceptable limits. The core technical issue lies in the function extractPivotTableFields, which retrieves field names using getPivotCacheFieldsName and subsequently trusts the value provided by the dataField fld attribute as a direct array index. In secure software design, any external input used to determine memory access locations must be rigorously validated against known boundaries before execution; however, Excelize fails to perform this essential check, assuming that the pivot-field count in the workbook metadata accurately reflects the actual number of fields available in the cache structure.
When an attacker constructs a malicious Excel file with a deliberate mismatch between the declared pivot-field count and the actual data content, or explicitly supplies an out-of-range value for the fld attribute, the library attempts to access memory at an invalid index location. Because Go does not perform implicit bounds checking on all slice accesses in every context without explicit safeguards, this unchecked index triggers a runtime panic that escapes the internal handling mechanisms of the library. This results in a denial of service condition where the process executing Excelize crashes unexpectedly. For applications relying on server-side processing of uploaded spreadsheets or automated data ingestion pipelines, such a crash can lead to significant operational disruption, requiring manual intervention to restart services and potentially causing data loss if transactions were not properly rolled back during the failure state.
From a classification perspective, this vulnerability aligns with CWE-125, Out-of-bounds Read, as it involves accessing memory beyond the intended boundary of an array or slice, although in Go's context, it primarily results in a panic rather than arbitrary code execution due to language safety features. It also relates closely to CWE-20, Improper Input Validation, specifically regarding the failure to validate that input data conforms to expected structural constraints before use. In terms of offensive security frameworks like MITRE ATT&CK, this flaw facilitates Denial of Service (T1499) by allowing an attacker to disrupt service availability through crafted inputs. The lack of a fixed version as of the review period indicates that immediate mitigation strategies are required for organizations dependent on these specific versions of Excelize.
To mitigate this risk in the absence of an official patch, developers must implement defensive coding practices within their own application layers or consider switching to alternative libraries if available. Implementing custom validation logic before passing workbook data to Excelize functions can help detect anomalies such as mismatched field counts or out-of-range indices. Additionally, wrapping calls to vulnerable functions like GetPivotTables in panic recovery mechanisms using Go's defer and recover statements can prevent the entire application from crashing when a malformed file is processed. This approach allows the system to log the error gracefully and continue operating rather than terminating abruptly. Organizations should also audit their dependency management systems to monitor for future updates or community-provided patches that address this specific bounds-checking deficiency in pivot table parsing logic.