CVE-2026-93451 in snappy-java
Summary
by MITRE • 09/18/2026
snappy-java through 1.1.10.8 contains a buffer overflow vulnerability in typed Snappy.uncompress*Array methods that allocate output arrays by dividing uncompressed length by element size but pass the undivided length to native code. Attackers controlling compressed input can cause misaligned length values to write past array bounds with attacker-controlled bytes, corrupting heap memory.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in snappy-java versions through 1.1.10.8 represents a critical buffer overflow condition rooted in improper boundary validation within the native decompression routines. Snappy is a widely used compression library known for its speed, and its Java implementation relies on JNI to interface with underlying C++ code that performs the actual data processing. The specific flaw resides in how output arrays are allocated and sized prior to being passed to these native methods. When handling typed array inputs or outputs, such as byte arrays representing integers or other primitive types, the library calculates the required buffer size by dividing the total uncompressed length by the element size of the target type. This calculation is intended to determine the number of elements needed for the Java-side array allocation. However, a critical logic error occurs when this calculated value is not correctly synchronized with the parameters passed to the native decompression function.
The core technical flaw involves a mismatch between the allocated buffer size and the length parameter provided to the underlying C++ code. While the Java layer allocates an array based on the divided element count, it subsequently passes the undivided uncompressed length directly to the native method responsible for writing the data into that array. Consequently, if the compressed input is controlled by an attacker, they can craft a payload where the uncompressed size suggests a large number of elements when treated as raw bytes but would result in a significantly smaller array if correctly divided by element size. The native code then proceeds to write data based on the full undivided length, effectively ignoring the bounds of the Java-allocated array. This discrepancy allows for writes that extend far beyond the allocated memory region into adjacent heap structures.
This buffer overflow condition leads directly to arbitrary heap memory corruption. By carefully crafting compressed input streams, an attacker can manipulate the decompression process to overwrite critical data structures located in memory immediately following the target array. Such overwrites can corrupt object headers, modify references to other objects, or alter integer values that control program flow. The impact of this vulnerability is severe because it undermines the fundamental safety guarantees provided by Java's managed runtime environment. Although Java typically protects against out-of-bounds access through strict bounds checking at the language level, the reliance on native code bypasses these protections once execution transitions to the JNI layer. This creates a pathway for memory corruption that can lead to application crashes, denial of service conditions due to segmentation faults or internal JVM errors, and potentially remote code execution if an attacker can precisely control the overwritten data to hijack control flow pointers.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow and CWE-787 Out-of-bounds Write. The attack vector is categorized under ATT&CK technique T1496 Resource Hijacking if the corruption leads to denial of service, or potentially T1055 Process Injection if the memory corruption allows for code execution within the process space. The vulnerability highlights the risks associated with JNI implementations where data types and sizes must be meticulously synchronized between managed and unmanaged code domains. Developers often assume that high-level language abstractions provide sufficient safety, but when interacting with native libraries, explicit validation of buffer boundaries is essential to prevent such discrepancies from being exploited.
Mitigation strategies for this vulnerability primarily involve upgrading the snappy-java library to version 1.1.10.9 or later, where the developers have corrected the logic error by ensuring that the length parameter passed to the native code matches the actual allocated array size rather than the raw uncompressed byte count. For environments unable to upgrade immediately, input validation at the application layer can serve as a temporary defense-in-depth measure. This involves verifying the integrity and expected sizes of compressed data before passing it to the decompression routines, although this is less effective against sophisticated attacks that may exploit other paths within the library. Organizations should also monitor for new releases from the snappy-java maintainers and apply patches promptly given the high severity associated with heap corruption vulnerabilities in widely used compression libraries. Regular security audits of JNI implementations are recommended to identify similar mismatches between allocated buffers and passed lengths in other components relying on native code integration.