CWE-190
AllowedInteger Overflow or Wraparound
Abstraction: Base · Status: Stable
The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.
4393 vulnerabilities reference this CWE, most recent first.
GHSA-FR5Q-2JXW-X8HG
Vulnerability from github – Published: 2023-09-01 18:30 – Updated: 2024-04-04 07:22Integer Overflow vulnerability in RELIC before commit 34580d840469361ba9b5f001361cad659687b9ab, allows attackers to execute arbitrary code, cause a denial of service, and escalate privileges when calling realloc function in bn_grow function.
{
"affected": [],
"aliases": [
"CVE-2023-36326"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-01T16:15:08Z",
"severity": "CRITICAL"
},
"details": "Integer Overflow vulnerability in RELIC before commit 34580d840469361ba9b5f001361cad659687b9ab, allows attackers to execute arbitrary code, cause a denial of service, and escalate privileges when calling realloc function in bn_grow function.",
"id": "GHSA-fr5q-2jxw-x8hg",
"modified": "2024-04-04T07:22:01Z",
"published": "2023-09-01T18:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36326"
},
{
"type": "WEB",
"url": "https://github.com/relic-toolkit/relic/commit/34580d840469361ba9b5f001361cad659687b9ab"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/relic-discuss/c/A_J2-ArVIAo/m/qgFiXsUJBQAJ?utm_medium=email\u0026utm_source=footer"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FR6J-324G-WRG2
Vulnerability from github – Published: 2022-05-13 01:24 – Updated: 2022-05-13 01:24Multiple integer overflows in the MDSS driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allow attackers to cause a denial of service or possibly have unspecified other impact via a large size value, related to mdss_compat_utils.c, mdss_fb.c, and mdss_rotator.c.
{
"affected": [],
"aliases": [
"CVE-2016-5344"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-08-30T17:59:00Z",
"severity": "CRITICAL"
},
"details": "Multiple integer overflows in the MDSS driver for the Linux kernel 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allow attackers to cause a denial of service or possibly have unspecified other impact via a large size value, related to mdss_compat_utils.c, mdss_fb.c, and mdss_rotator.c.",
"id": "GHSA-fr6j-324g-wrg2",
"modified": "2022-05-13T01:24:33Z",
"published": "2022-05-13T01:24:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5344"
},
{
"type": "WEB",
"url": "https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=1d2297267c24f2c44bd0ecb244ddb8bc880a29b7"
},
{
"type": "WEB",
"url": "https://www.codeaurora.org/integer-overflow-mdss-driver-cve-2016-5344"
},
{
"type": "WEB",
"url": "http://source.android.com/security/bulletin/2016-10-01.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/92695"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FR6W-XJ88-2FCH
Vulnerability from github – Published: 2022-05-17 02:41 – Updated: 2022-05-17 02:41In the Secure File System in all Android releases from CAF using the Linux kernel, an Integer Overflow to Buffer Overflow vulnerability could potentially exist.
{
"affected": [],
"aliases": [
"CVE-2014-9944"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-06T14:29:00Z",
"severity": "HIGH"
},
"details": "In the Secure File System in all Android releases from CAF using the Linux kernel, an Integer Overflow to Buffer Overflow vulnerability could potentially exist.",
"id": "GHSA-fr6w-xj88-2fch",
"modified": "2022-05-17T02:41:57Z",
"published": "2022-05-17T02:41:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9944"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-05-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98245"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FRH9-7WFP-W73P
Vulnerability from github – Published: 2025-12-10 09:30 – Updated: 2026-10-02 03:30A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.
{
"affected": [],
"aliases": [
"CVE-2025-14087"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-10T09:15:47Z",
"severity": "MODERATE"
},
"details": "A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.",
"id": "GHSA-frh9-7wfp-w73p",
"modified": "2026-10-02T03:30:58Z",
"published": "2025-12-10T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14087"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/glib/-/issues/3834"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2419093"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-14087"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:74674"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7461"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:72502"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:58981"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49512"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:25096"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22634"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21275"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19567"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19566"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19565"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19524"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19523"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19460"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19459"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19457"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19452"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19361"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19148"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:15971"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:15969"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:15953"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-FRP4-F42V-G8XW
Vulnerability from github – Published: 2025-01-21 12:30 – Updated: 2025-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
net/sctp: Prevent autoclose integer overflow in sctp_association_init()
While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow.
{
"affected": [],
"aliases": [
"CVE-2024-57938"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T12:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sctp: Prevent autoclose integer overflow in sctp_association_init()\n\nWhile by default max_autoclose equals to INT_MAX / HZ, one may set\nnet.sctp.max_autoclose to UINT_MAX. There is code in\nsctp_association_init() that can consequently trigger overflow.",
"id": "GHSA-frp4-f42v-g8xw",
"modified": "2025-11-03T21:32:15Z",
"published": "2025-01-21T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57938"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FRX6-6WJG-8W2P
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31Integer overflow or wraparound in Windows Kernel allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-54110"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T17:15:56Z",
"severity": "HIGH"
},
"details": "Integer overflow or wraparound in Windows Kernel allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-frx6-6wjg-8w2p",
"modified": "2025-09-09T18:31:21Z",
"published": "2025-09-09T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54110"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54110"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FV4P-HRVC-C34G
Vulnerability from github – Published: 2024-07-08 18:31 – Updated: 2024-07-09 18:30tap-windows6 driver version 9.26 and earlier does not properly check the size data of incomming write operations which an attacker can use to overflow memory buffers, resulting in a bug check and potentially arbitrary code execution in kernel space
{
"affected": [],
"aliases": [
"CVE-2024-1305"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-08T18:15:07Z",
"severity": "CRITICAL"
},
"details": "tap-windows6 driver version 9.26 and earlier does not properly \ncheck the size data of incomming write operations which an attacker can \nuse to overflow memory buffers, resulting in a bug check and potentially\n arbitrary code execution in kernel space",
"id": "GHSA-fv4p-hrvc-c34g",
"modified": "2024-07-09T18:30:43Z",
"published": "2024-07-08T18:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1305"
},
{
"type": "WEB",
"url": "https://community.openvpn.net/openvpn/wiki/CVE-2024-1305"
},
{
"type": "WEB",
"url": "https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg07534.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FW5P-PRJF-RQ4F
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-16 15:30An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. Connecting to a malicious NFS server may cause unexpected system termination or corrupt kernel memory.
{
"affected": [],
"aliases": [
"CVE-2026-84544"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:30Z",
"severity": "HIGH"
},
"details": "An integer overflow was addressed with improved input validation. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. Connecting to a malicious NFS server may cause unexpected system termination or corrupt kernel memory.",
"id": "GHSA-fw5p-prjf-rq4f",
"modified": "2026-09-16T15:30:47Z",
"published": "2026-09-14T21:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84544"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149035"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149042"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149043"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FW8F-W2G8-Q74W
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04In memory management driver, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-183461318
{
"affected": [],
"aliases": [
"CVE-2021-0494"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T17:15:00Z",
"severity": "HIGH"
},
"details": "In memory management driver, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-183461318",
"id": "GHSA-fw8f-w2g8-q74w",
"modified": "2022-05-24T19:04:58Z",
"published": "2022-05-24T19:04:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0494"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2021-05-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-FW94-4WWP-W8PW
Vulnerability from github – Published: 2026-10-07 20:22 – Updated: 2026-10-07 20:22Summary
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.
Reproduction, executed against HEAD 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.
What I verified and what I did not
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.
Attacker model
Any service that opens a spreadsheet it did not produce. The payload is 159 bytes, needs no authentication, and is deterministic.
Suggested fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/xuri/excelize/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.11.1-0.20260805032953-db93f8d89de7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107224"
],
"database_specific": {
"cwe_ids": [
"CWE-190",
"CWE-681"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:22:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nA Zip64 uncompressed-size of 2^63 casts to a negative int64 that bypasses the unzip-size guard and reaches make([]byte, 0, negativeCap)\n\nA 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`.\n\nThe guard, at `lib.go:44-46` on HEAD `ae2113b`:\n\n```go\nfileSize := v.FileInfo().Size()\nunzipSize += fileSize\nif unzipSize \u003e f.options.UnzipSizeLimit {\n\treturn fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)\n}\n```\n\n`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 \u003c\u003c 24`, `templates.go:193`) is false no matter how many such entries the archive contains.\n\nThe same negative value also fails the two stream-to-temp checks at `lib.go:53` and `lib.go:64` (`fileSize \u003e f.options.UnzipXMLSizeLimit`), so the entry is not diverted to a temp file and control reaches `readFile`:\n\n```go\n// lib.go:150\ndat := make([]byte, 0, file.FileInfo().Size())\n```\n\n`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.\n\nThe 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.\n\n## Reproduction, executed against HEAD `ae2113b` (go1.26.5)\n\nA 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`.\n\n```\nentry \"xl/worksheets/sheet1.xml\" FileInfo().Size() = -9223372036854775808\nexcelize.OpenReader(bytes.NewReader(raw)) -\u003e panic: runtime error: makeslice: cap out of range\n```\n\nControl, the identical archive with `UncompressedSize64 = 0x7FFFFFFFFFFFFFFF`:\n\n```\nentry \"xl/worksheets/sheet1.xml\" FileInfo().Size() = 9223372036854775807\nexcelize.OpenReader(bytes.NewReader(raw)) -\u003e err = \"unzip size exceeds the 16777216000 bytes limit\"\n```\n\nThe 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.\n\n## What I verified and what I did not\n\nI 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.\n\n## Attacker model\n\nAny service that opens a spreadsheet it did not produce. The payload is 159 bytes, needs no authentication, and is deterministic.\n\n## Suggested fix\n\nCompare against the limit in unsigned space, and bound the allocation independently rather than trusting the header:\n\n```go\nif v.UncompressedSize64 \u003e uint64(f.options.UnzipSizeLimit) {\n\treturn fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)\n}\n```\n\nand 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.",
"id": "GHSA-fw94-4wwp-w8pw",
"modified": "2026-10-07T20:22:45Z",
"published": "2026-10-07T20:22:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/security/advisories/GHSA-fw94-4wwp-w8pw"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/pull/2369"
},
{
"type": "WEB",
"url": "https://github.com/qax-os/excelize/commit/db93f8d89de71589069a54d1b998af02e3c5f7cd"
},
{
"type": "PACKAGE",
"url": "https://github.com/qax-os/excelize"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Excelize: A Zip64 uncompressed-size of 2^63 panics OpenFile/OpenReader"
}
Mitigation
Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- If possible, choose a language or compiler that performs automatic bounds checking.
Mitigation MIT-4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
- Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
- Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
Mitigation MIT-8
Strategy: Input Validation
- Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
- Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
Mitigation MIT-36
- Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
- Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-26
Strategy: Compilation or Build Hardening
Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.
CAPEC-92: Forced Integer Overflow
This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.