snappy-java CVE-2026-108104

Exploitation requires that the target application decompress attacker-supplied Snappy *framed* data specifically through SnappyFramedInputStream, and that this stream draw from a buffer pool shared across multiple concurrently-active streams - the cross-stream exposure only manifests when a double-released pooled buffer is handed to another live stream. The concrete trigger is a frame whose declared chunk length is large enough that the replacement allocation fails with OutOfMemoryError along the path near SnappyFramedInputStream.java:243. Limiting factors: the leak is opportunistic, not deterministic (reflected by AT:P), there is no impact on single-stream or non-pooled usage, applications using the classic SnappyInputStream rather than the framed variant are not affected by this specific path, and only versions 1.1.7.4 through 1.1.10.9 are vulnerable.

This is a medium-severity (CVSS 4.0 base 6.3) memory-safety flaw in a widely-embedded Java library, best characterized as a real-but-conditional risk rather than an urgent emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) indicates network-reachable, unauthenticated exploitation but with AT:P - meaning a specific attack requirement (the race/allocation-failure condition) must be met, which materially lowers reliability. Impact is limited and split: VC:L and VI:L (low confidentiality and integrity) with VA:N (no availability impact claimed in the vendor vector, even though the trigger itself is an OutOfMemoryError). No KEV listing, no EPSS score, and no public exploit were provided, so exploitation is currently theoretical: no public exploit identified at time of analysis. The strongest mitigating signals are the AT:P attack requirement and the need for a shared buffer pool serving multiple concurrent streams, which make the cross-stream data leak opportunistic rather than attacker-controlled. The strongest aggravating signal is the library's enormous transitive-dependency footprint across the Java data ecosystem. Net: patch on a normal cadence, prioritized above cosmetic issues but below any network-facing unauthenticated RCE. Note: no EPSS data was supplied, so exploitation probability cannot be quantified from the input.

An attacker submits a specially crafted Snappy framed stream whose frame header declares an extremely large chunk length to a service that decompresses untrusted input via SnappyFramedInputStream from a shared buffer pool. The oversized declaration forces a replacement buffer allocation that fails with OutOfMemoryError, causing the same pooled buffer to be released twice; a second, concurrent stream then draws that same backing array and reads or clobbers the attacker's-or-victim's decompressed data. No public exploit code is known, and the AT:P attack requirement makes the cross-stream leak opportunistic rather than deterministic.