CVE-2026-107224: Excelize: A Zip64 uncompressed-size of 2^63 panics OpenFile/OpenReader
A Zip64 uncompressed-size of 2^63 casts to a negative int64 that bypasses the unzip-size guard and reaches make([]byte, 0, negativeCap)
A Zip64 uncompressed-size in the range [2^63, 2^64) casts to a negative int64 in zip.File.FileInfo().Size(), and ReadZipReader does signed arithmetic on that value, so the total-decompression guard is bypassed and the negative size reaches make([]byte, 0, size) in readFile. A 159-byte crafted file panics OpenFile and OpenReader with runtime error: makeslice: cap out of range.
The guard, at lib.go:44-46 on HEAD ae2113b:
fileSize := v.FileInfo().Size()
unzipSize += fileSize
if unzipSize > f.options.UnzipSizeLimit {
return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)
}
FileInfo().Size() returns int64(UncompressedSize64). UncompressedSize64 is read from the Zip64 extended-information extra record in the central directory and is fully attacker controlled, so any value with the top bit set arrives as a negative int64. unzipSize then goes negative and the comparison against UnzipSizeLimit (default 1000 << 24, templates.go:193) is false no matter how many such entries the archive contains.
The same negative value also fails the two stream-to-temp checks at lib.go:53 and lib.go:64 (fileSize > f.options.UnzipXMLSizeLimit), so the entry is not diverted to a temp file and control reaches readFile:
// lib.go:150
dat := make([]byte, 0, file.FileInfo().Size())
make with a negative capacity panics. There is no recover() in any non-test file in the library, so the panic leaves the public API and takes down the calling goroutine.
The asymmetry inside this same function is the clearest way to see it: unzipToTemp (lib.go:83) handles an entry with a plain io.Copy and never pre-allocates from the declared size, so it is indifferent to whatever the header claims. Only the pre-allocating branch trusts that number, and it trusts it after a signed comparison that a wrapped value walks straight through.
References
Code Behaviors & Features
Detect and mitigate CVE-2026-107224 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →