CVE-2026-107220 in excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.7.1 to 2.11.0, mergeCellsParser leaves the cached rectangle empty for an empty mergeCell ref and then passes that empty slice to cellInRange without a length check. GetCellValue reaches mergeCellsParser, which passes an empty rectangle derived from the mergeCell ref attribute into cellInRange. When a crafted worksheet contains an empty mergeCell ref and a non-streaming cell API reads the worksheet, cellInRange indexes four positions in an empty slice, allowing an attacker to panic on the first affected cell operation. 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.7.1 through 2.11.0, represents a critical input validation failure that leads to application instability and potential denial of service conditions. Excelize serves as a widely utilized Go language library for parsing and generating Microsoft Excel spreadsheet files, making it a foundational component in many data processing pipelines where automated reading or writing of XLSX formats is required. The core issue resides within the internal logic responsible for handling merged cell regions, specifically involving the interaction between the mergeCellsParser function and the cellInRange helper routine. This flaw exploits the assumption that all referenced cells in an Excel document will contain valid coordinate data, failing to account for malformed or empty references which can be introduced by maliciously crafted input files.
The technical mechanism of this vulnerability begins when a user invokes non-streaming cell API functions to read values from a worksheet containing specific merge cell configurations. The execution flow directs the operation toward the mergeCellsParser function, which is tasked with interpreting the mergeCell ref attributes defined in the underlying XML structure of the XLSX file. In standard operations, this parser extracts coordinate ranges and caches them for efficient access. However, when encountering an empty mergeCell reference attribute, the parser incorrectly leaves the cached rectangle as an empty slice rather than handling it as a null or invalid case. This empty slice is subsequently passed directly to the cellInRange function without any preliminary length verification. The lack of boundary checking allows subsequent operations to proceed under the false premise that valid coordinate data exists within the slice.
The operational impact manifests when the cellInRange function attempts to index into this empty slice at four distinct positions, a process that assumes the presence of data elements corresponding to row and column indices. In Go, attempting to access an element in a zero-length slice results in a runtime panic due to out-of-bounds indexing errors. Consequently, any attempt by an attacker or automated system to read values from cells associated with such malformed merge references will cause the application utilizing Excelize to crash abruptly. This constitutes a classic denial of service scenario where availability is compromised without requiring authentication or elevated privileges, provided that the crafted file can be uploaded or processed by the vulnerable software component. The absence of error handling for this specific edge case means that even minor deviations in XML structure within merge cell definitions can trigger system failure.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write or Read (specifically out-of-bounds read leading to panic). The attack vector is categorized under ATT&CK technique T1496 Resource Hijacking via Denial of Service, as the primary objective achievable through exploitation is the disruption of service availability. While this specific flaw does not directly lead to remote code execution in its current form due to Go's memory safety guarantees preventing arbitrary code injection from a panic, it severely impacts system reliability and can be leveraged in conjunction with other vulnerabilities or within high-throughput environments to exhaust resources by repeatedly triggering crashes requiring process restarts.
Mitigation strategies for this vulnerability are currently constrained by the fact that no fixed version is available as of the review period. Organizations relying on Excelize must therefore implement defensive coding practices at the application layer rather than waiting for a library patch. This includes validating input files before processing them with Excelize, potentially using static analysis tools or custom parsers to detect malformed merge cell references prior to invoking read operations. Additionally, implementing panic recovery mechanisms within Go applications can prevent total system crashes by catching runtime panics and allowing graceful degradation of service rather than complete failure. Until an official patch is released from the maintainers, treating all incoming XLSX files as untrusted and applying strict schema validation against expected merge cell structures remains the most effective temporary countermeasure to mitigate this risk.