GITHUB.COM/360ENTSECGROUP-SKYLAR/EXCELIZE/V2 · CVE-2026-107224 · Package
FIX → 2.11.1-0.20260805032953-db93f8d89de7
A crafted XLSX file with a Zip64 uncompressed size of 2^63 makes the Excelize Go library panic when opened with OpenFile or OpenReader. The likely result is a crash of the program that parses the file, a denial of service; the sources do not say whether code execution or data exposure is possible.
first public Aug 5, 2026 · 3 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Programs that use the Excelize Go library to open XLSX files, especially files from users or other untrusted sources, are exposed. The sources do not describe a specific configuration; programs that only open trusted, internally generated spreadsheets are less exposed. The sources do not say whether the 360EntSecGroup-Skylar import path has a fixed version.
Not affected if trusted-files-only
Who cares cwe-190, cwe-681, excelize, go, spreadsheet-upload
github.com/xuri/excelize/v2 or github.com/360EntSecGroup-Skylar/excelize/v2 in go.mod and check the version.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 {
fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)
}
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
go list -m github.com/xuri/excelize/v2 in the module to see the resolved version.Upgrade to 2.11.1-0.20260805032953-db93f8d89de7
github.com/xuri/excelize/v2 fixed at 2.11.1-0.20260805032953-db93f8d89de7github.com/360EntSecGroup-Skylar/excelize/v2: fixed version unknownFileInfo().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.
ae2113b (go1.26.5)A 159-byte archive was built with one stored entry named xl/worksheets/sheet1.xml: truthful 1-byte local header, central-directory 32-bit uncompressed size set to the 0xFFFFFFFF Zip64 sentinel, and a Zip64 extra record (tag 0x0001, data size 8) declaring UncompressedSize64 = 0x8000000000000000.
entry "xl/worksheets/sheet1.xml" FileInfo().Size() = -9223372036854775808
excelize.OpenReader(bytes.NewReader(raw)) -> panic: runtime error: makeslice: cap out of range
Control, the identical archive with UncompressedSize64 = 0x7FFFFFFFFFFFFFFF:
entry "xl/worksheets/sheet1.xml" FileInfo().Size() = 9223372036854775807
excelize.OpenReader(bytes.NewReader(raw)) -> err = "unzip size exceeds the 16777216000 bytes limit"
The control isolates the defect to the sign flip rather than to size magnitude: the guard behaves correctly for any positive declared size and fails only once the value wraps. archive/zip itself accepts the archive without complaint, so nothing upstream of excelize rejects it.
I ran both cases above myself and confirmed each cited line at HEAD. I caught the panic with a deliberate recover in my harness so I could print it; nothing in excelize recovers it, which I checked by grepping every non-test .go file. I did not separately run the OpenFile variant, since OpenFile reaches the same ReadZipReader loop, and I did not attempt to turn the bypassed size cap into a separate decompression-bomb primitive.
Any service that opens a spreadsheet it did not produce. The payload is 159 bytes, needs no authentication, and is deterministic.
Compare against the limit in unsigned space, and bound the allocation independently rather than trusting the header:
if v.UncompressedSize64 > uint64(f.options.UnzipSizeLimit) {
return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)
}
and in readFile, reject or clamp a declared size that is negative or larger than the limit before calling make. The same unsigned treatment applies to the two UnzipXMLSizeLimit comparisons, which currently route a wrapped size away from the safe streaming path and into the pre-allocating one.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Go Vulnerability Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain · GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.