CVE-2026-108106

Updated on 09 Oct 2026

Severity

8.7 High severity

Details

CVSS score
8.7
CVSS vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Overview

About vulnerability

Impact

Several decompression paths in snappy-java allocate an output buffer sized by the uncompressed length declared in the first bytes of the compressed data, before decompressing or validating it. A few bytes of crafted input can therefore force an allocation of up to 2 GB, causing OutOfMemoryError (denial of service), or a NegativeArraySizeException for declared lengths of 2^31 or more.

Affected entry points include Snappy.uncompress(byte[]), Snappy.uncompressString, the Snappy.uncompress*Array methods, SnappyInputStream, and SnappyFramedInputStream. The maxChunkSize limit added for CVE-2023-43642 bounds only the compressed chunk length, so it does not prevent this.

Patches

Fixed in 1.1.10.9 (#739). Snappy.uncompressedLength() now rejects negative declared lengths, and lengths larger than any valid Snappy stream of the given size can produce. The densest Snappy element expands 3 bytes to 64, so the limit is 64/3 of the compressed size. Allocations are therefore proportional to the input actually received.

Workarounds

Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.

Details