CVE-2023-34453 is an integer overflow vulnerability in snappy-java, the widely used Java port of Google's Snappy compression library, that lets a crafted input crash the JVM with a denial of service. It affects every release before 1.1.10.1 and carries a CVSS 3.1 base score of 5.9 (Medium). It shipped as part of a cluster of three snappy-java bugs disclosed together in mid-2023, and because snappy-java is a transitive dependency of Kafka, Cassandra, Spark, and dozens of other data platforms, the blast radius is much larger than the raw download count suggests.
What causes CVE-2023-34453
The bug lives in BitShuffle.java, in the family of shuffle() functions that rearrange primitive arrays before compression. Each shuffle() variant multiplies the input array's length by a type-specific size: 4 bytes for an int, 8 for a long or double, 2 for a short, and so on. That multiplication has no bounds check.
Java's int tops out at 2,147,483,647. If the array length times the type multiplier exceeds that ceiling, the value wraps around and becomes negative or nonsensically small. snappy-java then uses the wrapped value to size a buffer. Depending on which way the arithmetic lands, the JVM throws a NegativeArraySizeException or an ArrayIndexOutOfBoundsException. Either way, the thread doing the shuffle dies, and if that thread was handling a request or a stream, the service goes down with it.
This is a textbook CWE-190 (Integer Overflow or Wraparound). There is no memory corruption and no code execution — the JVM's own bounds checking turns the overflow into an exception rather than a heap smash. The impact is availability only, which is why the CVSS score sits at 5.9 rather than in the high range.
Which versions are affected
Every snappy-java release before 1.1.10.1 is vulnerable. The fix landed in 1.1.10.1. To find what your build actually resolves, ask Maven or Gradle for the dependency tree rather than reading your top-level POM, because you almost certainly get snappy-java transitively:
mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java
For Gradle:
./gradlew dependencyInsight --dependency snappy-java
If either prints something in the 1.1.8.x or 1.1.9.x range, you are exposed. A common sighting is snappy-java-1.1.8.4.jar, which is the version many older Kafka and Spark builds pulled in.
Why the transitive angle matters
Almost nobody adds snappy-java to their build on purpose. It arrives underneath Apache Kafka clients, Cassandra, Spark, Parquet, and various serialization stacks that use Snappy as their default codec. That means the version you run is chosen by whatever pinned it upstream, not by you.
The practical consequence is that upgrading snappy-java directly can conflict with the version your parent library expects. Before you force the version, check whether a newer release of the parent library already bumped its snappy-java pin. Kafka, for instance, moved to a patched snappy-java in later 3.x releases, so upgrading Kafka can close CVE-2023-34453 for you without any explicit override.
How to remediate CVE-2023-34453
Upgrade to snappy-java 1.1.10.1 or later. This is the direct fix. The patched code validates the multiplication before allocating, so an oversized array produces a clean, handled error instead of an uncaught exception that kills the thread.
In Maven, if a transitive dependency is holding you back, pin the version explicitly in dependencyManagement:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.xerial.snappy</groupId>
<artifactId>snappy-java</artifactId>
<version>1.1.10.5</version>
</dependency>
</dependencies>
</dependencyManagement>
In Gradle, a resolution strategy does the same job:
configurations.all {
resolutionStrategy {
force 'org.xerial.snappy:snappy-java:1.1.10.5'
}
}
Test the codec path after forcing the version. snappy-java ships native libraries, and forcing a version override occasionally exposes a mismatch between the Java wrapper and the bundled native binary. Run your compression-heavy integration tests, not just a unit suite, before you ship the bump.
If you manage a fleet of services and want to know which ones actually resolve a vulnerable snappy-java rather than eyeballing each build, an SCA tool such as Safeguard can trace the transitive path and tell you which parent dependency pinned it, which is usually the fastest route to a clean upgrade.
The other two snappy-java CVEs
CVE-2023-34453 was disclosed alongside CVE-2023-34454 (a similar overflow in the compress() path) and CVE-2023-34455 (an unchecked chunk-length DoS in the stream reader). All three are fixed in the same 1.1.10.1 release, so a single upgrade closes the whole set. If your scanner flags one of them, assume the others are present too and remediate them together rather than one ticket at a time.
FAQ
How serious is CVE-2023-34453?
It is a Medium-severity denial-of-service issue with a CVSS 3.1 base score of 5.9. It cannot execute code or leak data; the worst outcome is a crashed thread or downed service when snappy-java processes a maliciously sized array.
What version of snappy-java fixes CVE-2023-34453?
Version 1.1.10.1 contains the patch. Any release from 1.1.10.1 onward is safe; everything before it is vulnerable.
Do I need to worry about it if I never call snappy-java directly?
Possibly yes. snappy-java is a transitive dependency of Kafka, Cassandra, Spark, and other data tools. If any of those process untrusted compressed input on a vulnerable version, the DoS is reachable even though your code never imports the library.
Does upgrading Kafka fix CVE-2023-34453?
It can. Later Kafka 3.x releases bumped their snappy-java pin to a patched version, so upgrading the parent library often closes the CVE without an explicit override. Check your resolved dependency tree to confirm.