CVE-2023-34455 is a denial-of-service vulnerability in snappy-java caused by an unchecked chunk length in its stream reader, which lets an attacker crash the JVM with a single crafted input. It affects releases up to and including 1.1.10.0 (everything before the 1.1.10.1 fix) and carries a CVSS 3.1 base score of 7.5 (High). It is the highest-scoring member of the three snappy-java bugs disclosed together in 2023, and like its siblings it reaches far because snappy-java rides along under Kafka, Spark, and other data infrastructure.
What CVE-2023-34455 does
The problem is in the SnappyInputStream chunk-reading logic, specifically the hasNextChunk function. When snappy-java reads a compressed stream, it pulls four bytes off the wire and treats them as the length of the next chunk. It then uses that length to allocate a byte array. The four bytes are never validated before the allocation.
That trust is the whole bug. An attacker who controls the stream can put whatever they like in those four bytes:
- Send
0xFFFFFFFF, which Java interprets as -1, and the allocation throwsjava.lang.NegativeArraySizeException. - Send
0x7FFFFFFF, roughly 2.1 GB, and the JVM tries to allocate an array that large and dies with a fataljava.lang.OutOfMemoryError.
Either outcome takes down the thread reading the stream, and typically the service around it. This maps to CWE-770 (Allocation of Resources Without Limits or Throttling). It is network-exploitable with low complexity, no privileges, and no user interaction, with impact confined to availability — hence the 7.5 score.
Which versions are affected
Every snappy-java release up to and including 1.1.10.0 is vulnerable. The fix is in 1.1.10.1. Because you almost never depend on snappy-java directly, inspect the resolved dependency tree rather than your top-level build file:
mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java
A frequent hit is snappy-java-1.1.8.4.jar, which shipped inside a lot of older Kafka and OpenSearch builds. Anything in the 1.1.8.x or 1.1.9.x line, or 1.1.10.0 itself, is exposed.
Why the fix is straightforward but the rollout is not
The patch is simple: version 1.1.10.1 validates the chunk length against a sane maximum before it allocates anything, so a bogus length produces a handled error instead of a crash. Upgrading is the entire remediation.
The friction is that snappy-java is somebody else's transitive dependency. Forcing a newer version can collide with the range your parent library expects, and snappy-java's bundled native binaries mean an override occasionally needs a real integration test to shake out. The cleanest fix is often to upgrade the parent — a newer Kafka or Spark release that already pins a patched snappy-java — rather than pinning the transitive directly.
How to remediate CVE-2023-34455
Upgrade to snappy-java 1.1.10.1 or later. If a transitive path is pinning an old version, override it. In Maven:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.xerial.snappy</groupId>
<artifactId>snappy-java</artifactId>
<version>1.1.10.5</version>
</dependency>
</dependencies>
</dependencyManagement>
In Gradle:
configurations.all {
resolutionStrategy {
force 'org.xerial.snappy:snappy-java:1.1.10.5'
}
}
Do not rely on catching the exception as a fix. Wrapping the decompression call in a try/catch that swallows OutOfMemoryError is not remediation. An OutOfMemoryError can leave the JVM in an inconsistent state, and you are still doing the giant allocation before you catch anything. Fix the version so the oversized allocation never happens.
Validate untrusted stream sources. If your service decompresses Snappy streams that originate from outside your trust boundary — an upload endpoint, a message from an external producer, a third-party feed — that is exactly the reachable path this CVE cares about. Prioritize those services over internal-only pipelines where the compressed data is already trusted.
To find which services in a fleet actually resolve a vulnerable snappy-java and which parent library pinned it, an SCA tool such as Safeguard can walk the transitive graph so you are not opening mvn dependency:tree on every repo by hand.
Fix all three snappy-java CVEs at once
CVE-2023-34455 was published alongside CVE-2023-34453 and CVE-2023-34454, both integer-overflow DoS bugs in the same library. All three are patched in the single 1.1.10.1 release. If a scanner surfaces any one of them, treat the upgrade as closing the whole set rather than filing three separate tickets.
FAQ
How severe is CVE-2023-34455?
It is High severity, with a CVSS 3.1 base score of 7.5. The impact is denial of service only: an attacker can crash the JVM but cannot execute code or read data.
What version of snappy-java fixes CVE-2023-34455?
Version 1.1.10.1 and later. The patch validates the chunk length before allocating a buffer, so a malicious length is rejected instead of triggering a NegativeArraySizeException or OutOfMemoryError.
Is CVE-2023-34455 exploitable if my streams come from trusted sources?
The reachable danger is decompressing data an attacker can influence. If every Snappy stream your service reads originates inside your trust boundary, practical exploitability is low, though the vulnerable code is still present and worth patching.
How is CVE-2023-34455 different from CVE-2023-34453?
CVE-2023-34455 is an unchecked chunk-length allocation in the stream reader; CVE-2023-34453 is an integer overflow in the BitShuffle code. Both are DoS bugs and both are fixed in snappy-java 1.1.10.1.