Xerial snappy-java CVE-2026-108106

Exploitation requires that the target application passes attacker-controlled compressed bytes to one of the vulnerable entry points - Snappy.uncompress, Snappy.uncompressString, SnappyInputStream, or SnappyFramedInputStream - using snappy-java before 1.1.10.9; the crafted input declares an oversized uncompressed length in the compressed header, forcing allocations up to 2 GB before the data is validated. No authentication or user interaction is required (PR:N/UI:N). The key limiting factor is reachability: the flaw is only exploitable where untrusted/externally-supplied Snappy data is decompressed; applications that decompress only trusted internal data are not practically exposed, and the impact is bounded to availability (OutOfMemoryError / JVM denial of service) with no data disclosure or modification.

This is a denial-of-service-only flaw (CWE-789 unbounded memory allocation) in the widely-embedded snappy-java compression library. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 8.7 HIGH and indicates remote, unauthenticated, low-complexity triggering with no user interaction, but the impact is confined to availability (VA:H; VC:N/VI:N) - there is no confidentiality or integrity exposure, so the raw High score reflects easy exploitation of a single-dimension (DoS) impact rather than a full system compromise. Exploitation status is 'no public exploit identified at time of analysis': the input contains no KEV listing and no POC/exploit-code signal, and no EPSS probability was supplied, so widespread automated exploitation cannot be asserted. The realistic risk is conditional: the CVSS AV:N assumes the vulnerable decompression methods are reachable with attacker-controlled bytes, which is true only where an application feeds untrusted compressed data to Snappy; for such internet-facing data pipelines this is a genuine patch priority, whereas deployments that only decompress trusted internal data face low practical risk. Missing data to note explicitly: no EPSS score and no KEV/POC flags were provided, so exploitation likelihood is inferred solely from the CVSS vector and description, not confirmed.

An attacker submits a small, crafted Snappy-compressed payload to an application endpoint that decompresses untrusted input (e.g. a message/upload handler calling Snappy.uncompress or wrapping the stream in SnappyInputStream). The payload's header declares a very large uncompressed length, causing the library to allocate up to 2 GB before validating the data, triggering OutOfMemoryError and crashing or stalling the JVM. No public exploit code is identified in the provided data, but the attack requires only a few crafted bytes and no authentication.