NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
MEDIUM severity

CVE-2023-34454 — snappy-java

MEDIUMFix: xerial/snappy-java@d004255

CVE-2023-34454 is a medium-severity (CVSS 5.9) CWE-190 vulnerability in org.xerial.snappy:snappy-java. A fix is available for org.xerial.snappy:snappy-java — see the affected versions and patch details below.

snappy-java's Integer Overflow vulnerability in compress leads to DoS

Also known asGHSA-fjpj-2g6w-x25r
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2023-34454.

EPSS Exploitation Probability

via FIRST.org ↗
1.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs74th percentile — riskier than 74% of all scored CVEsHighest risk
0.17%0.77%1.37%1.97%0.7%1.5%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
☕org.xerial.snappy:snappy-java

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Due to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error.

Impact

Denial of Service

Description

The function compress(char[] input) in the file Snappy.java receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress function.

public static byte[] compress(char[] input)
            throws IOException
    {
        return rawCompress(input, input.length * 2); // char uses 2 bytes
    }

Since the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.

    public static byte[] rawCompress(Object data, int byteSize)
            throws IOException
    {
        byte[] buf = new byte[Snappy.maxCompressedLength(byteSize)];
        int compressedByteSize = impl.rawCompress(data, 0, byteSize, buf, 0);
        byte[] result = new byte[compressedByteSize];
        System.arraycopy(buf, 0, result, 0, compressedByteSize);
        return result;
    }

Since the maxCompressedLength function treats the length as an unsigned integer, it doesn’t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a “java.lang.NegativeArraySizeException” exception will be raised while trying to allocate the array “buf”. On the other side, if the result is positive, the “buf” array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error. The same issue exists also when using the “compress” functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won’t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.

Steps To Reproduce

Compile and run the following code:

package org.example;
import org.xerial.snappy.Snappy;

import java.io.*;

public class Main {

    public static void main(String[] args) throws IOException {
        char[] uncompressed = new char[0x40000000];
        byte[] compressed = Snappy.compress(uncompressed);
    }
}

The program will crash, creating crashdumps and showing the following error (or similar):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000063a01c20, pid=21164, tid=508
#
.......

Alternatively - compile and run the following code:

package org.example;
import org.xerial.snappy.Snappy;

import java.io.*;

public class Main {

    public static void main(String[] args) throws IOException {
        char[] uncompressed = new char[0x3fffffff];
        byte[] compressed = Snappy.compress(uncompressed);
    }
}

The program will crash with the following error (or similar), since the maxCompressedLength returns a value that is interpreted as negative by java:

Exception in thread "main" java.lang.NegativeArraySizeException: -1789569677
	at org.xerial.snappy.Snappy.rawCompress(Snappy.java:425)
	at org.xerial.snappy.Snappy.compress(Snappy.java:172)
	at org.example.Main.main(Main.java:10)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.xerial.snappy:snappy-javaall versions1.1.10.1org.xerial.snappy:snappy-java:1.1.10.1

Affected Products

1 product · 1 configurations
Application
snappy-javaxerial
< 1.1.10.1
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.xerial.snappy:snappy-java, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update org.xerial.snappy:snappy-java to 1.1.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-34454 is resolved across your whole dependency graph.

  3. Workarounds

    Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate
ProductFixed inAdvisory
Red Hat AMQ Streams 2.5.0see advisoryRHSA-2023:5165
Red Hat build of Quarkus 2.13.9snappy-javaRHSA-2023:7700

Frequently Asked Questions

## Summary Due to unchecked multiplications, an integer overflow may occur, causing an unrecoverable fatal error. ## Impact Denial of Service ## Description The function [compress(char[] input)](https://github.com/xerial/snappy-java/blob/05c39b2ca9b5b7b39611529cc302d3d796329611/src/main/java/org/xerial/snappy/Snappy.java#L169) in the file [Snappy.java](https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/Snappy.java) receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the [rawCompress](https://github.com/xe
O3 Security · Impact-Aware SCA

Is CVE-2023-34454 in your dependencies?

Find it across Maven, including transitive dependencies.

CVE-2023-34454: snappy-java DoS — Fixed in 1.1.10.1