Threats Tagged 'cwe-681'

CVE-2026-83872 is a high-severity vulnerability in Microsoft Windows 10 Version 1607 involving incorrect conversion between numeric types in the Windows TCP/IP stack. This flaw allows an authorized local attacker to elevate privileges. The vulnerability affects multiple Windows 10 builds and has an official fix available from Microsoft.

CVE-2026-106432 is a low-severity vulnerability in the MongoDB PHP Driver where the BSON encoder incorrectly converts string lengths to a 32-bit value without validation. This can cause a heap buffer overflow when encoding strings near 4 GiB in size, potentially corrupting process memory or terminating the PHP process. Exploitation requires a non-default runtime configuration that allows multi-gigabyte values, and no interaction with the MongoDB server is needed.

### Summary 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`: ```go 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`: ```go // 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: ```go 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.

CVE-2026-47539 is a vulnerability in the NVIDIA Virtual GPU Manager for Linux involving incorrect numeric type conversion in the kernel mode layer. Exploitation could lead to severe impacts including code execution, denial of service, privilege escalation, information disclosure, and data tampering. The vulnerability has a CVSS score of 6.7, indicating a medium severity level. No affected versions or patch information are provided in the available data.

CVE-2026-47508 is a vulnerability in the NVIDIA GeForce GPU Display Driver for Windows and Linux. It involves an incorrect conversion between numeric types in the kernel mode layer. Exploitation could allow code execution, denial of service, privilege escalation, information disclosure, and data tampering. The vulnerability has a high severity score of 7.8 CVSS 3.1. No specific affected versions or patch information is provided.

RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, readField in read.go reads the length of an AMQP byte-array field with type tag x into a signed int32 and passes the value directly to make when allocating the field buffer. A malicious or compromised broker can encode a value such as 0xFFFFFFFF, which becomes -1 and causes a len out of range runtime panic. The panic escapes the network reader goroutine and terminates the client process, including during connection.start server properties or message header table parsing. This issue is fixed in version 1.13.0.

CVE-2026-69438 is a high-severity vulnerability in Microsoft Windows 10 Version 1607 and related versions involving incorrect conversion between numeric types in Microsoft JScript. This flaw allows an unauthorized attacker to execute code remotely over a network without user interaction. The vulnerability affects multiple Windows 10 builds prior to specific patched versions. An official fix is available from Microsoft.

CVE-2026-84963 is a medium severity vulnerability in the MongoDB C Driver's BSON library where incorrect numeric conversion during JSON parsing can cause large text values to be truncated or omitted without error. This may lead to applications holding altered data that does not match the submitted input. The issue affects specific versions of the MongoDB C Driver and can be triggered by unauthenticated input.

An incorrect numeric type conversion in the BSON document building component of the MongoDB C++ Driver may cause a length value to be interpreted incorrectly. When an application supplies an extremely large, non-terminated field name to the builder, the library may read memory outside the intended buffer and terminate the calling process. No authentication is required, but the calling application must pass the oversized name in a specific form.

A numeric truncation weakness exists in the JSON parsing component of the MongoDB C++ Driver's BSON library. An actor who controls the text that an embedding application hands to the library's public JSON parsing interface, when that text is very large, can cause the library to read memory beyond the supplied buffer and return it to the caller, to silently accept only part of the input as a complete document, or to terminate the process. No MongoDB server, credentials, or non-default configuration is required; the effect is confined to the process that uses the library.