CVE-2026-107217 in excelize
Summary
by MITRE • 10/07/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified within the Excelize library, specifically affecting versions from 2.0.0 through 2.11.0 in github.com/xuri/excelize/v2 and from 1.1.0 through 1.4.1 in github.com/xuri/excelize, represents a critical integer overflow issue rooted in the handling of spreadsheet column identifiers. Excelize is widely utilized for programmatically reading and writing Microsoft Excel spreadsheets using the Go programming language. The core flaw resides within the ColumnNameToNumber function, which is responsible for converting alphabetic column labels such as A, BZ, or AA into their corresponding numerical indices used internally by the library to access data structures. This conversion process relies on a bijective base-26 arithmetic system where each letter represents a digit in a positional numeral system without a zero value. However, the implementation fails to implement necessary bounds checking for integer overflow when processing column names that exceed the maximum capacity of an int64 variable. Consequently, excessively long or crafted column identifiers can cause the calculated numerical index to wrap around due to arithmetic underflow, resulting in a significantly smaller and often invalid positive number rather than triggering an error condition as expected by secure coding standards.
The operational impact of this vulnerability is severe because it directly leads to application instability through process termination via panic. When a crafted Excel worksheet contains cell references utilizing these overflowing column names, the library proceeds with normal processing workflows that depend on accurate index mapping. Specifically, functions such as checkSheetR0 and xlsxWorksheet.checkRow utilize the result from ColumnNameToNumber to determine row and column boundaries during sheet normalization. Because the overflow causes the large positive integer to wrap into a value that is subsequently interpreted incorrectly or treated as zero in certain contexts, it disrupts the internal array indexing logic. In Go, accessing an array slice with an index that falls outside its valid bounds typically triggers a runtime panic. Since this occurs within critical parsing routines, any application relying on Excelize to process untrusted or maliciously crafted spreadsheet files will experience immediate termination of the calling process. This constitutes a straightforward Denial of Service attack vector where no code execution is required from the attacker's perspective; simply providing a malformed file with specific column headers is sufficient to crash the service processing it.
From a security classification standpoint, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound and CWE-248 Uncaught Exception. The failure to detect overflow before using the value in array indexing operations violates fundamental principles of defensive programming outlined in standards such as OWASP Secure Coding Practices. Furthermore, within the context of the MITRE ATT&CK framework, this behavior facilitates Availability Impact through process termination, which can be categorized under techniques that disrupt service availability by exploiting software bugs rather than traditional exploitation methods like buffer overflows leading to code execution. The absence of input validation for extreme values allows an attacker to exploit the predictable nature of integer arithmetic in compiled languages to force a state where the application cannot recover gracefully.
Mitigation strategies must focus on implementing rigorous input validation and bounds checking prior to performing arithmetic operations that could result in overflow. Developers integrating Excelize should ensure they are using patched versions if available, although current reviews indicate no fixed version exists at this time. In the interim, applications consuming spreadsheet data from untrusted sources should implement a preprocessing layer or wrapper around the library calls to validate column names against expected length constraints before passing them to ColumnNameToNumber. Additionally, implementing panic recovery mechanisms within Go applications can prevent total process termination by catching runtime panics and logging errors instead of crashing entirely. Long-term remediation requires upstream contributions to the Excelize project to add explicit checks for integer limits during base-26 conversion logic, ensuring that any column name resulting in a value exceeding int64 max or min thresholds returns an error rather than wrapping around silently. Until such patches are released and adopted by downstream consumers, strict filtering of input data remains the primary defense against this denial-of-service vector.