Live › vulnerability › GHSA-94x4-5g3f-jjxp
Go to dashboardsnappy-java before 1.1.10.9 trusts an uncompressed length declared inside compressed input and allocates up to 2 GB for it. A few crafted bytes passed to decompression calls can cause OutOfMemoryError and a denial of service.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 15:34 UTC. All times on this page are UTC.
Any Java or JVM application that depends on snappy-java below 1.1.10.9 and decompresses data an outside party can supply, such as network payloads, uploads or message queue contents. Applications that only decompress data they produced themselves are much less exposed. Teams with no snappy-java dependency can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| org.xerial.snappy:snappy-java | maven | < 1.1.10.9 | – |
mvn dependency:tree | grep snappy-javaSnappy.uncompress, Snappy.uncompressString, SnappyInputStream or SnappyFramedInputStream that handle untrusted inputorg.xerial.snappy:snappy-java to 1.1.10.9 or later, as the advisory's fixed version (the advisory itself is withdrawn as a duplicate of GHSA-q233-g92q-qxp6)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
This advisory has been withdrawn because it is a duplicate of GHSA-q233-g92q-qxp6. This link is maintained to preserve external references.
Xerial snappy-java before 1.1.10.9 contains an unbounded memory allocation vulnerability that allows attackers to exhaust JVM memory by declaring a large uncompressed length in compressed input. Attackers can supply a few crafted bytes to Snappy.uncompress, uncompressString, SnappyInputStream or SnappyFramedInputStream to force allocations up to 2 GB, causing OutOfMemoryError and denial of service.
This page as .md · .json · in your agent: get_signal("GHSA-94x4-5g3f-jjxp")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.