CVE-2026-107223 in excelize
Summary
by MITRE • 10/07/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in the Excelize library, a widely used Go language package for manipulating Microsoft Excel spreadsheet files, represents a critical resource exhaustion flaw stemming from insufficient input validation during column range processing. This issue affects versions ranging from 2.1.0 through 2.11.0 and specifically impacts functions that modify worksheet columns, such as SetColWidth. The core technical defect lies within the internal flatCols function, which is responsible for expanding file-loaded column ranges into a linear format suitable for manipulation. When this function processes data derived from an external Excel file, it fails to validate whether the Min and Max attributes of the specified column range adhere to the standard worksheet column limits defined by the XLSX specification. This lack of boundary checking allows maliciously crafted files containing oversized column maximum values to bypass internal safeguards entirely.
The operational mechanism of this vulnerability involves a chain of function calls initiated when an application invokes a column mutator like SetColWidth on a compromised workbook. Upon receiving such a request, the library delegates processing to flatCols, which proceeds to expand the xlsxCol.Min and xlsxCol.Max values without enforcing the MaxColumns constraint inherent to Excel file structures. This expansion triggers a deep copy operation followed by an append action for every column number selected within the attacker-defined range. Because there is no upper limit enforced on this process, an adversary can specify an exceptionally large maximum value in the crafted XML data embedded within the XLSX file. Consequently, the library attempts to allocate memory and compute resources proportional to this inflated range, leading to a disproportionate consumption of system resources relative to the actual size or utility of the spreadsheet content.
The impact of this vulnerability is primarily characterized by Denial of Service conditions resulting from excessive CPU usage and memory exhaustion. As flatCols iterates through the artificially expanded column range, it consumes significant amounts of RAM for each deep copy operation performed on the underlying data structures. In environments where Excelize is used to process user-uploaded files or untrusted inputs in real-time applications such as web servers or API endpoints, this behavior can quickly lead to an Out-of-Memory (OOM) state. This results in the termination of the application process, causing service disruption for legitimate users. The severity is heightened by the fact that no fixed version was available at the time of review, leaving organizations relying on these specific versions exposed to potential exploitation without a direct patch from the maintainers.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to properly control the allocation and retention of system resources based on external input. It also relates closely to CWE-20, Improper Input Validation, specifically regarding the failure to validate data against expected structural constraints before processing. In terms of offensive security frameworks such as MITRE ATT&CK, this flaw facilitates resource exhaustion attacks that can be leveraged for Denial of Service objectives within cloud or enterprise environments where automated file parsing is common. The absence of a fixed version necessitates immediate defensive measures rather than simple patching.
Mitigation strategies must focus on input sanitization and architectural safeguards since an official update is not yet available. Developers should implement custom validation logic to check column indices against the maximum allowed columns (typically 16384 for modern XLSX files) before passing them to Excelize functions that trigger flatCols. Additionally, integrating resource limits such as Go runtime memory constraints or using context timeouts can help contain potential runaway processes. It is also advisable to audit all code paths involving SetColWidth and similar column manipulation APIs to ensure they are not processing untrusted data without prior validation. Until a patched version of the library is released, treating Excel files from unknown sources with extreme caution and applying strict size and structure constraints at the ingestion layer remains the most effective defense against this resource exhaustion vector.