snappy-java EUVD-2026-82604

Requires the target application to call snappy-java's Snappy.compress(ByteBuffer, ByteBuffer) overload with a destination ByteBuffer whose remaining capacity is smaller than the compressed output, and to feed it attacker-influenceable incompressible data (random/encrypted bytes that Snappy cannot shrink). Applications that use the byte[]-based compress API, size destination buffers with Snappy.maxCompressedLength(), or never compress untrusted input are not exposed. Impact is limited to availability (JVM crash / process termination); there is no confidentiality or integrity impact and no code execution, so the practical limiter is whether the vulnerable ByteBuffer overload sits on a path reachable with untrusted, low-compressibility input.

This is an availability-only defect, not a code-execution flaw despite the CWE-787 (out-of-bounds write) classification. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) is explicit that confidentiality and integrity are unaffected (VC:N/VI:N) and only availability is high (VA:H) - the described impact is off-heap memory corruption leading to JVM termination, i.e. a crash/DoS, not attacker-controlled code execution. My independent 3.1 mapping is 7.5 (C:N/I:N/A:H), lower than the 8.7 shown, because 4.0's scoring weights network availability impact more aggressively than 3.1 does. No EPSS score, KEV listing, or POC is present in the supplied intelligence, so there is no public-exploitation signal - real-world urgency rests on how widely the specific vulnerable API path is reachable rather than on observed attacks. A key caveat: exploitation is not universal to every snappy-java consumer - it requires the application to invoke the two-ByteBuffer Snappy.compress(ByteBuffer, ByteBuffer) overload with an undersized destination buffer and attacker-influenceable (incompressible) input, so the AV:N/PR:N/AC:L vector reflects the theoretical library API surface, not a guaranteed remote-crash of any deployment. Treat as a moderate-priority availability/robustness fix, especially for services that compress untrusted data via the ByteBuffer API.

A service that compresses client-supplied data using snappy-java's Snappy.compress(ByteBuffer, ByteBuffer) overload receives incompressible (e.g. already-random/encrypted) input that, once 'compressed', exceeds the destination ByteBuffer's remaining capacity. The library writes past the destination buffer end, corrupting off-heap memory and crashing the JVM, taking down the service. No public exploit code is identified in the provided data; the VulnCheck advisory and GitHub issue #732 describe the mechanism.