CVE-2026-108106: Xerial snappy-java before 1.1.10.9 Unbounded Memory Allocation Denial of Service
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.uncompressArray 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.
Other sources
Xerial snappy-java before 1.1.10.9 contains an unbounded memory allocation vulnerability that allows attackers to exhaust JVM memory by declaring a large uncompressed length in compressed input. Attackers can supply a few crafted bytes to Snappy.uncompress, uncompressString, SnappyInputStream or SnappyFramedInputStream to force allocations up to 2 GB, causing OutOfMemoryError and denial of service.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.xerial.snappy:snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9 - Upgrade
Upgrade
xerial/snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9 - Compensating control
Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Applications using snappy-java before 1.1.10.9 are exposed if they pass attacker-controlled or otherwise untrusted compressed Snappy data to Snappy.uncompress, uncompressString, SnappyInputStream, or SnappyFramedInputStream.
What does an attacker need to exploit it?
An attacker only needs to supply crafted compressed input that declares a very large uncompressed length. The input can be only a few bytes, and no authentication, user interaction, or special conditions are indicated.
What is the operational impact?
The affected decompression paths can allocate up to 2 GB of JVM memory based on the declared length. This can trigger OutOfMemoryError and deny service to the affected application.
How can I remediate the issue?
Upgrade org.xerial.snappy:snappy-java to version 1.1.10.9 or later. If an immediate upgrade is not possible, avoid passing untrusted compressed input to the affected Snappy decompression APIs.