CVE-2026-108106
ADVISORY - githubSummary
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.
Common Weakness Enumeration (CWE)
Memory Allocation with Excessive Size Value
Allocation of Resources Without Limits or Throttling
NIST
3.9
CVSS SCORE
8.7highGitHub
CVSS SCORE
7.5highDebian
-
Ubuntu
-
CVSS SCORE
N/AmediumRed Hat
3.9