Live › vulnerability › CVE-2026-108106
Go to dashboardsnappy-java allocates an output buffer sized by the uncompressed length declared in the first bytes of its input, before checking the data. A few bytes of crafted compressed input can force a near 2 GB allocation, causing an OutOfMemoryError or NegativeArraySizeException and a denial of service.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 15:34 UTC, 0h before NVD. All times on this page are UTC.
Applications that depend on snappy-java at 1.1.10.8 or earlier and decompress data that an outside party can supply, such as request bodies, uploaded files or messages from other systems. Services that only decompress data they produce themselves are much less exposed. Teams on 1.1.10.9 or later are not affected.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| org.xerial.snappy:snappy-java | maven | <= 1.1.10.8 | 1.1.10.9 |
mvn dependency:tree | grep snappy-java in the project and read the resolved version.Snappy.uncompress, Snappy.uncompressString, SnappyInputStream or SnappyFramedInputStream.org.xerial.snappy:snappy-java to 1.1.10.9 or later.Snappy.uncompressedLength(input) and reject input whose declared length exceeds an application-specific limit before decompressing.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
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.
Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.
This page as .md · .json · in your agent: get_signal("CVE-2026-108106")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.