Advisory Database
  • Advisories
  • Dependency Scanning
  1. golang
  2. ›
  3. github.com/xuri/excelize/v2
  4. ›
  5. CVE-2026-107224

CVE-2026-107224: Excelize: A Zip64 uncompressed-size of 2^63 panics OpenFile/OpenReader

October 7, 2026

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

  • github.com/advisories/GHSA-fw94-4wwp-w8pw
  • github.com/qax-os/excelize/commit/db93f8d89de71589069a54d1b998af02e3c5f7cd
  • github.com/qax-os/excelize/pull/2369
  • github.com/qax-os/excelize/security/advisories/GHSA-fw94-4wwp-w8pw
  • nvd.nist.gov/vuln/detail/CVE-2026-107224

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 →

Affected versions

All versions starting from 2.1.0 before 2.11.1-0.20260805032953-db93f8d89de7

Fixed versions

  • 2.11.1-0.20260805032953-db93f8d89de7

Solution

Upgrade to version 2.11.1-0.20260805032953-db93f8d89de7 or above.

Impact 6.5 MEDIUM

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Learn more about CVSS

Weakness

  • CWE-190: Integer Overflow or Wraparound
  • CWE-681: Incorrect Conversion between Numeric Types

Source file

go/github.com/xuri/excelize/v2/CVE-2026-107224.yml

Spotted a mistake? Edit the file on GitLab.

  • Site Repo
  • About GitLab
  • Terms
  • Privacy Statement
  • Contact

Page generated Sun, 08 Nov 2026 00:17:26 +0000.