CVE-2026-107224 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, a Zip64 uncompressed size with the high bit set is converted from uint64 to a negative int64 before signed size-limit checks and allocation. ReadZipReader obtains UncompressedSize64 through FileInfo.Size and passes the wrapped negative value to readFile. When a crafted Zip64 entry declares an uncompressed size from 2^63 through 2^64-1 and the workbook is opened, the negative size bypasses unzip limits and reaches make as a negative capacity, allowing an attacker to panic during workbook opening. 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 in the Excelize library, specifically affecting versions from 2.1.0 through 2.11.0, represents a critical integer overflow issue rooted in improper type conversion and validation logic within the Zip64 parsing mechanism. Excelize is widely used for programmatic manipulation of Microsoft Excel files, relying on Go standard libraries to handle archive formats including ZIP and its extended variant, Zip64. The core technical flaw occurs during the processing of file entries where the uncompressed size field in a Zip64 header exceeds 2^63 bytes. In such cases, the raw value is read as an unsigned 64-bit integer but is subsequently cast to a signed 64-bit integer without proper boundary checks or masking. This conversion causes values greater than 9,223,372,036,854,775,807 (the maximum value for int64) to wrap around into negative numbers due to two's complement arithmetic representation.
This type confusion creates a significant bypass in the security controls designed to prevent resource exhaustion attacks. The function ReadZipReader retrieves the uncompressed size via FileInfo.Size and passes this potentially corrupted negative integer directly to readFile without validating that it remains within positive bounds or expected limits for memory allocation. Standard unzip implementations typically enforce strict upper limits on file sizes to mitigate Denial of Service risks, but these checks rely on the assumption that size values are non-negative integers. By receiving a negative value due to the overflow, the crafted Zip64 entry effectively bypasses these protective thresholds because most conditional logic treats negative numbers as smaller than any positive limit or handles them in unexpected ways depending on the specific comparison operator used.
The operational impact of this vulnerability is primarily a Denial of Service condition triggered during the opening of maliciously constructed Excel workbooks. When an attacker provides a file with a Zip64 entry declaring an uncompressed size within the range of 2^63 to 2^64-1, the application proceeds to allocate memory based on the negative capacity derived from the overflowed value. In Go, attempting to create a slice or array with a negative length typically results in a runtime panic rather than returning an error gracefully. This causes the entire process handling the workbook opening to crash abruptly, leading to service unavailability for any system relying on Excelize to parse user-uploaded documents. There is no fixed version available as of this review, leaving users exposed until upstream mitigation strategies are implemented or workarounds such as input validation at a higher layer are applied.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-253 Incorrect Check of Function Return Value if the underlying allocation function fails silently before panic occurs in other contexts. It also maps to MITRE ATT&CK technique T1496 Resource Hijacking under Denial of Service, as an attacker can exhaust system resources by forcing repeated crashes or memory mismanagement events. To mitigate this risk in the absence of a patched library version, developers should implement strict input validation before passing file metadata to Excelize functions. This includes verifying that all size fields are within reasonable bounds and explicitly checking for negative values after any type conversions involving archive headers. Additionally, wrapping calls to Excelize operations with panic recovery mechanisms can prevent application crashes from propagating to the broader system, although this is a defensive coding practice rather than a root cause fix.