CVE-2026-108104 in snappy-java
Summary
by MITRE • 10/09/2026
Xerial snappy-java from 1.1.7.4 before 1.1.10.10 contains a double release vulnerability in SnappyFramedInputStream that returns pooled buffers twice when replacement allocation fails. Attackers can supply framed data with a large declared chunk length to trigger OutOfMemoryError, causing shared backing arrays that expose or overwrite other streams' decompressed data.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in Xerial snappy-java versions prior to 1.1.10.10 represents a critical memory management flaw within the SnappyFramedInputStream component, specifically categorized under CWE-415 Double Free. This issue arises from an improper handling of pooled byte buffers during the decompression process when allocation for replacement buffers fails. The core technical defect lies in the reference counting mechanism used to manage these pooled resources. When a stream attempts to allocate new memory for processing incoming data and this operation is unsuccessful, the library incorrectly proceeds to release references to existing pooled buffers that are still actively being utilized by other concurrent operations or subsequent parts of the same decompression session. This double release action corrupts the internal state of the buffer pool manager, leading to undefined behavior in how shared backing arrays are managed across different stream instances.
From an operational perspective, this flaw allows for a severe denial-of-service condition and potential data integrity compromise. An attacker can exploit this vulnerability by supplying specially crafted framed Snappy data that declares an excessively large chunk length. This malformed input triggers the allocation failure path within the decompression logic, thereby activating the double release sequence. The immediate consequence is typically an OutOfMemoryError or a similar catastrophic exception due to memory corruption and pool exhaustion. However, beyond simple service disruption, the corruption of shared backing arrays poses a significant risk to data confidentiality and integrity. Because multiple streams may share underlying buffer pools for performance optimization, the improper release can lead to one stream's decompressed data being exposed to another unintended recipient or overwritten by subsequent operations. This effectively creates a side-channel where sensitive information from other active sessions could be leaked into memory regions accessible to malicious actors controlling the input stream.
This vulnerability aligns with ATT&CK techniques related to resource exhaustion and potential impact on availability, as well as implications for data confidentiality if the shared buffer corruption allows cross-stream data leakage. The lack of proper synchronization or reference validation during error handling paths is a common pattern in high-performance compression libraries that prioritize throughput over strict safety checks under failure conditions. Mitigation strategies must focus primarily on upgrading to version 1.1.10.10 or later, where the buffer management logic has been corrected to prevent double releases and ensure proper isolation of pooled resources even during allocation failures. For environments unable to upgrade immediately, implementing input validation to limit maximum chunk sizes can reduce the likelihood of triggering the specific code path that leads to this error state. Additionally, deploying network-level controls such as rate limiting or payload size restrictions on endpoints accepting Snappy-compressed data can provide a layer of defense against exploitation attempts aimed at inducing memory exhaustion conditions.