CVE-2026-90559 in snappy-java
Summary
by MITRE • 09/12/2026
snappy-java through 1.1.10.8 contains an out-of-bounds write vulnerability in Snappy.uncompress(ByteBuffer, ByteBuffer) because destination buffer capacity is never validated against decompressed size. Attackers can supply valid compressed data that decompresses larger than the destination buffer, causing writes past buffer boundaries and JVM termination.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/12/2026
The snappy-java library, specifically through version 1.1.10.8, contains a critical out-of-bounds write vulnerability within its Snappy.uncompress method when processing data via Java NIO ByteBuffers. This flaw stems from a fundamental lack of input validation regarding the capacity of the destination buffer relative to the expected size of the decompressed payload. The underlying implementation fails to verify whether the provided ByteBuffer has sufficient space to accommodate the full extent of the uncompressed data before initiating the write operation. Consequently, when an attacker supplies compressed data that expands significantly upon decompression, the library proceeds with the memory copy without checking if the destination buffer is large enough, leading directly to a heap-based buffer overflow condition within the Java Virtual Machine environment.
From a technical perspective, this vulnerability exploits the assumption that application-level code will always provide adequately sized buffers for decompression operations. In standard Snappy compression algorithms, data can expand by a small factor, but in malicious scenarios or specific edge cases involving crafted inputs, the expansion ratio can be manipulated to exceed available memory allocations within the buffer. Because Java ByteBuffers are direct wrappers around underlying arrays or native memory segments, writing past their allocated boundaries corrupts adjacent memory structures. This corruption typically manifests as immediate JVM termination due to segmentation faults or access violations in the underlying operating system, effectively resulting in a Denial of Service condition for any application relying on this library for data processing tasks.
The operational impact of this vulnerability is primarily centered around service availability and potential stability issues within enterprise systems that utilize snappy-java for high-performance compression and decompression workloads. While the primary immediate effect is a crash or termination of the Java process, buffer overflows in native memory interfaces can sometimes lead to more severe consequences depending on how the JVM handles the exception and what other processes are running concurrently. Attackers could potentially leverage this instability to disrupt critical services, cause data loss due to abrupt shutdowns, or create conditions that might be chained with other vulnerabilities for further exploitation. The lack of bounds checking makes it trivially easy for remote attackers to trigger these crashes by simply sending specially crafted compressed payloads through any API endpoint exposed to external input.
This vulnerability aligns closely with CWE-787: Out-of-bounds Write, as the core issue involves writing data beyond the allocated limits of a buffer in memory. It also relates to CWE-20: Improper Input Validation, since the library fails to adequately validate that the destination capacity matches or exceeds the decompressed size before performing the operation. In terms of attack vectors and tactics, this flaw can be mapped to MITRE ATT&CK techniques involving resource exhaustion or denial of service, particularly if exploited in a distributed environment where multiple nodes are processing untrusted compressed data streams. The vulnerability highlights the risks associated with low-level memory manipulation libraries that abstract away direct pointer arithmetic but still rely on correct buffer sizing from higher-level application code without enforcing strict internal checks.
To mitigate this risk, organizations should immediately upgrade snappy-java to version 1.1.10.9 or later, where developers have implemented proper validation logic to check the destination buffer capacity against the decompressed size before proceeding with the write operation. For systems that cannot be updated instantly due to dependency constraints, implementing a wrapper layer around the Snappy.uncompress method is recommended. This wrapper should explicitly calculate the expected uncompressed length from the compressed header and verify it against the target ByteBuffer's remaining capacity prior to invocation. Additionally, input validation strategies at the application level can help filter out unusually large compression ratios or malformed payloads before they reach the library. Regular security audits of third-party dependencies are essential to identify such low-level memory safety issues that may not be immediately apparent through functional testing but pose significant stability and security risks in production environments.