GHSA-Q233-G92Q-QXP6
Vulnerability from github – Published: 2026-10-27 15:33 – Updated: 2026-10-27 15:33Impact
Several decompression paths in snappy-java allocate an output buffer sized by the uncompressed length declared in the first bytes of the compressed data, before decompressing or validating it. A few bytes of crafted input can therefore force an allocation of up to 2 GB, causing OutOfMemoryError (denial of service), or a NegativeArraySizeException for declared lengths of 2^31 or more.
Affected entry points include Snappy.uncompress(byte[]), Snappy.uncompressString, the Snappy.uncompress*Array methods, SnappyInputStream, and SnappyFramedInputStream. The maxChunkSize limit added for CVE-2023-43642 bounds only the compressed chunk length, so it does not prevent this.
Patches
Fixed in 1.1.10.9 (#739). Snappy.uncompressedLength() now rejects negative declared lengths, and lengths larger than any valid Snappy stream of the given size can produce. The densest Snappy element expands 3 bytes to 64, so the limit is 64/3 of the compressed size. Allocations are therefore proportional to the input actually received.
Workarounds
Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.10.8"
},
"package": {
"ecosystem": "Maven",
"name": "org.xerial.snappy:snappy-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.10.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-108106"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-27T15:33:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nSeveral decompression paths in snappy-java allocate an output buffer sized by the uncompressed length declared in the first bytes of the compressed data, before decompressing or validating it. A few bytes of crafted input can therefore force an allocation of up to 2 GB, causing `OutOfMemoryError` (denial of service), or a `NegativeArraySizeException` for declared lengths of 2^31 or more.\n\nAffected entry points include `Snappy.uncompress(byte[])`, `Snappy.uncompressString`, the `Snappy.uncompress*Array` methods, `SnappyInputStream`, and `SnappyFramedInputStream`. The `maxChunkSize` limit added for CVE-2023-43642 bounds only the compressed chunk length, so it does not prevent this.\n\n### Patches\nFixed in 1.1.10.9 (#739). `Snappy.uncompressedLength()` now rejects negative declared lengths, and lengths larger than any valid Snappy stream of the given size can produce. The densest Snappy element expands 3 bytes to 64, so the limit is 64/3 of the compressed size. Allocations are therefore proportional to the input actually received.\n\n### Workarounds\nBefore decompressing untrusted data, check that `Snappy.uncompressedLength(input)` is within an application-specific limit.",
"id": "GHSA-q233-g92q-qxp6",
"modified": "2026-10-27T15:33:22Z",
"published": "2026-10-27T15:33:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/security/advisories/GHSA-q233-g92q-qxp6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108106"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/pull/739"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/commit/943c6043a292568575e8347af4507d015e802c75"
},
{
"type": "PACKAGE",
"url": "https://github.com/xerial/snappy-java"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/blob/v1.1.10.8/src/main/java/org/xerial/snappy/Snappy.java#L517"
},
{
"type": "WEB",
"url": "https://github.com/xerial/snappy-java/releases/tag/v1.1.10.9"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/xerial-snappy-java-before-1.1.10.9-unbounded-memory-allocation-denial-of-service"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "snappy-java: Unbounded memory allocation from attacker-declared uncompressed lengtha"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.