CVE-2026-93452: snappy-java Buffer Overflow Vulnerability

CVE-2026-93452 Overview

CVE-2026-93452 is a buffer overflow vulnerability in snappy-java through version 1.1.10.8. The flaw resides in the Snappy.compress(ByteBuffer, ByteBuffer) method, which writes past the end of the destination buffer when compressing incompressible input. An attacker who controls the input data can force the compressor to overrun the destination buffer's remaining capacity. This corrupts off-heap memory managed by the Java Virtual Machine (JVM) and terminates the process. The weakness is classified as an out-of-bounds write [CWE-787] and affects any Java service that exposes snappy-java compression to untrusted input.

Critical Impact
Remote attackers can crash JVM processes that use snappy-java for compression by supplying crafted incompressible data, producing a denial of service against dependent services.

Affected Products

snappy-java through version 1.1.10.8
Java applications embedding org.xerial.snappy for ByteBuffer compression
Downstream frameworks and data pipelines that expose Snappy.compress to untrusted input

Discovery Timeline

2026-09-18 - CVE-2026-93452 published to the National Vulnerability Database (NVD)
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93452

Vulnerability Analysis

The Snappy.compress(ByteBuffer src, ByteBuffer dst) API compresses bytes from a source ByteBuffer into a destination ByteBuffer. The implementation does not verify that the destination has enough remaining capacity to hold the worst-case compressed output. Snappy's format expands incompressible input by adding framing and literal-run overhead. When an attacker supplies data that resists compression, the emitted output exceeds dst.remaining(). The native compressor continues writing past the buffer boundary into adjacent off-heap memory. Because the write occurs in native code operating on direct memory, the JVM aborts with a fatal error rather than throwing a Java exception. Services that call Snappy.compress on attacker-controlled payloads therefore fail catastrophically.

Root Cause

The root cause is missing capacity validation in the ByteBuffer compression path at Snappy.java line 137. The method should require dst.remaining() >= Snappy.maxCompressedLength(src.remaining()) before invoking the native compressor. Instead, it trusts the caller to size the destination buffer correctly and passes both buffers to native code without bounds enforcement.

Attack Vector

Exploitation requires only that an attacker submit or influence data that reaches Snappy.compress(ByteBuffer, ByteBuffer). Any network-facing service, message broker, or storage layer that compresses inbound records with snappy-java can be triggered remotely without authentication. The result is JVM termination and denial of service for the hosting application.

No verified public exploit code is available. Technical details are documented in the GitHub Snappy-Java Issue #732 and the VulnCheck Buffer Overflow Advisory.

Detection Methods for CVE-2026-93452

Indicators of Compromise

JVM hard crashes accompanied by hs_err_pid*.log files referencing libsnappyjava or org.xerial.snappy.SnappyNative.rawCompress
Unexpected process exits on services that ingest external data through Snappy-compressed channels
Repeated large or high-entropy payloads submitted to endpoints that invoke Snappy.compress

Detection Strategies

Inventory Java applications and identify dependencies on org.xerial:snappy-java at or below 1.1.10.8 using software composition analysis
Alert on JVM fatal error logs (SIGSEGV, EXCEPTION_ACCESS_VIOLATION) whose stack traces include SnappyNative frames
Correlate application crash telemetry with inbound request patterns showing incompressible or randomized payloads

Monitoring Recommendations

Forward JVM crash dumps and application logs to a centralized analytics platform for anomaly detection
Track process restart frequency for services handling Kafka, Parquet, or other Snappy-compressed data streams
Monitor traffic volume and payload entropy on endpoints that expose compression functionality to external clients

How to Mitigate CVE-2026-93452

Immediate Actions Required

Upgrade snappy-java to a fixed version above 1.1.10.8 as soon as the maintainers publish a patched release
Audit application code for direct calls to Snappy.compress(ByteBuffer, ByteBuffer) on data sourced from untrusted callers
Restrict or authenticate network endpoints that funnel external data into Snappy compression routines

Patch Information

Refer to the GitHub Snappy-Java Repository and GitHub Snappy-Java Issue #732 for the fix status and release notes. Update transitive dependencies pulled in through frameworks such as Kafka, Hadoop, Spark, and Parquet after confirming compatibility.

Workarounds

Size the destination ByteBuffer to at least Snappy.maxCompressedLength(src.remaining()) before every compress call
Wrap compression calls in size checks that reject inputs exceeding safe payload thresholds
Prefer the byte[]-based Snappy.compress overloads where feasible, since they allocate the destination internally
Enforce input validation and rate limits at the application boundary to reduce exposure to malicious payloads

bash

# Configuration example: pin a fixed snappy-java version in Maven once available
# Replace <FIXED_VERSION> with the maintainer-published patched release
mvn dependency:tree | grep snappy-java
# In pom.xml:
# <dependency>
#   <groupId>org.xerial.snappy</groupId>
#   <artifactId>snappy-java</artifactId>
#   <version><FIXED_VERSION></version>
# </dependency>