CVE-2026-116590: 
Java vulnerability analysis and mitigation

CVE-2026-116590 is a JVM crash vulnerability in snappy-java (a Java port of Google's Snappy compression library) caused by unchecked array ranges passed to native memcpy operations. The flaw exists in Snappy.arrayCopy(), SnappyOutputStream.rawWrite(), and SnappyInputStream.rawRead(), where caller-supplied negative or oversized byteLength and offset values are forwarded to native code without validation, enabling out-of-bounds memory access. All versions prior to 1.1.10.9 of org.xerial.snappy:snappy-java are affected. The vulnerability was disclosed on October 26–27, 2026, with a fix released in version 1.1.10.9. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Feedly).

The root cause is improper validation of array indices (CWE-129) and out-of-bounds write (CWE-787). The Snappy.arrayCopy(Object src, int offset, int byteLength, Object dest, int destOffset) method passed caller-controlled offset and byteLength parameters directly to a native memcpy call without first verifying that the ranges fall within the bounds of the source and destination arrays. This allowed negative or oversized values to trigger reads or writes outside array boundaries, crashing the JVM. Additionally, typed-array byte-size calculations in stream read/write methods could overflow int, producing incorrect in-range offsets that bypass logical checks. The fix in PR #741 adds explicit range validation in Snappy.arrayCopy, introduces a checkElementRange helper for typed-array methods, and rejects byte-size calculations that overflow int (GitHub Advisory, GitHub PR #741, Commit 2d7ca71).

Successful exploitation causes a JVM crash, resulting in a denial of service for any application relying on snappy-java for compression or decompression. There is no confidentiality or integrity impact — the vulnerability is limited to availability (CVSS A:H, C:N, I:N). Applications that accept externally supplied data and pass it through snappy-java stream or array operations are at risk, including data pipelines, messaging systems, and distributed storage frameworks that use snappy-java as a dependency (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.407%, reflecting a low probability of exploitation in the near term. Exploitation requires high attack complexity (AC:H) and no privileges or user interaction, meaning an unauthenticated network attacker must be able to supply malicious input to a snappy-java compression/decompression operation (GitHub Advisory, Feedly).

1. Identify target: Locate a network-accessible application that uses snappy-java versions prior to 1.1.10.9 and exposes an endpoint that accepts user-controlled data passed to snappy-java compression or decompression operations (e.g., a data ingestion API, messaging broker, or file upload service).
2. Craft malicious input: Prepare input that, when processed by the application, results in a call to SnappyOutputStream.rawWrite(), SnappyInputStream.rawRead(), or Snappy.arrayCopy() with a negative or oversized byteLength or offset value — for example, by supplying a typed array with a range whose byte size overflows int.
3. Submit the payload: Send the crafted input to the target endpoint via the application's normal interface (e.g., HTTP request, message queue submission).
4. Trigger JVM crash: The unvalidated range is forwarded to the native memcpy, causing an out-of-bounds memory access that crashes the JVM, resulting in a denial of service for the application (GitHub Advisory, GitHub PR #741).

• Logs: Unexpected JVM crash logs (hs_err_pid*.log) referencing native memory access violations or segmentation faults originating from snappy-java native library calls (libsnappyjava).
• Process: Sudden, unexplained JVM process termination in applications using snappy-java, particularly following receipt of external compressed or uncompressed data.
• Application Logs: IndexOutOfBoundsException, IllegalArgumentException, or SnappyError (with code TOO_LARGE_INPUT) stack traces in application logs referencing Snappy.arrayCopy, SnappyOutputStream.rawWrite, or SnappyInputStream.rawRead — these indicate exploitation attempts against patched versions or boundary probing.
• Network: Repeated requests to data ingestion or compression endpoints with anomalously large or malformed payload sizes, particularly if followed by application restarts.

Upgrade org.xerial.snappy:snappy-java to version 1.1.10.9 or later, which adds bounds validation in Snappy.arrayCopy and all typed-array stream read/write methods before invoking native code (GitHub Release v1.1.10.9, GitHub Advisory). As a temporary workaround if upgrading is not immediately possible, validate all offset and length parameters against array bounds before passing them to snappy-java APIs. Applications and downstream dependencies (e.g., Hadoop, Kafka, Spark) that bundle snappy-java should also be reviewed and updated to ensure they pull in the patched version.