GHSA-6CX8-RJF8-PR8G
Vulnerability from github – Published: 2026-10-07 16:17 – Updated: 2026-10-07 16:17Summary
LZ4DecompressorWithLength.decompress(byte[], int) allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says 0x40000000 makes the JVM commit a gigabyte and can cause heap exhaustion.
Details
net.jpountz.lz4.LZ4DecompressorWithLength reads the header and passes it straight on:
final int destLen = getDecompressedLength(src, srcOff);
return fastDecompressor.decompress(src, srcOff + 4, destLen);
and net.jpountz.lz4.LZ4FastDecompressor allocates it:
public final byte[] decompress(byte[] src, int srcOff, int destLen) {
final byte[] decompressed = new byte[destLen];
decompress(src, srcOff, decompressed, 0, destLen);
return decompressed;
}
getDecompressedLength performs no validation: no comparison against src.length, no ceiling, no rejection of negatives. LZ4SafeDecompressor.decompress(byte[], int, int, int) has the same shape with maxDestLen.
The sibling overload that callers pass their own buffer to, decompress(src, srcOff, dest, destOff, destLen), is fine, because there destLen is chosen by the caller rather than by the input. The bug is specific to the convenience overloads that take the size from the header, and that difference is the whole finding.
Impact
Any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte message. On a service that decompresses request bodies, a few concurrent 5-byte requests exhaust the heap. No privileges are needed, only the ability to get bytes into the decompressor. Confidentiality and integrity are untouched.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.1"
},
"package": {
"ecosystem": "Maven",
"name": "at.yawk.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106453"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T16:17:47Z",
"nvd_published_at": "2026-10-06T20:17:27Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`LZ4DecompressorWithLength.decompress(byte[], int)` allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says `0x40000000` makes the JVM commit a gigabyte and can cause heap exhaustion.\n\n### Details\n\n`net.jpountz.lz4.LZ4DecompressorWithLength` reads the header and passes it straight on:\n\n```java\nfinal int destLen = getDecompressedLength(src, srcOff);\nreturn fastDecompressor.decompress(src, srcOff + 4, destLen);\n```\n\nand `net.jpountz.lz4.LZ4FastDecompressor` allocates it:\n\n```java\npublic final byte[] decompress(byte[] src, int srcOff, int destLen) {\n final byte[] decompressed = new byte[destLen];\n decompress(src, srcOff, decompressed, 0, destLen);\n return decompressed;\n}\n```\n\n`getDecompressedLength` performs no validation: no comparison against `src.length`, no ceiling, no rejection of negatives. `LZ4SafeDecompressor.decompress(byte[], int, int, int)` has the same shape with `maxDestLen`.\n\nThe sibling overload that callers pass their own buffer to, `decompress(src, srcOff, dest, destOff, destLen)`, is fine, because there `destLen` is chosen by the caller rather than by the input. The bug is specific to the convenience overloads that take the size from the header, and that difference is the whole finding.\n\n### Impact\n\nAny application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte message. On a service that decompresses request bodies, a few concurrent 5-byte requests exhaust the heap. No privileges are needed, only the ability to get bytes into the decompressor. Confidentiality and integrity are untouched.",
"id": "GHSA-6cx8-rjf8-pr8g",
"modified": "2026-10-07T16:17:48Z",
"published": "2026-10-07T16:17:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-6cx8-rjf8-pr8g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106453"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/commit/6492ce5aca6bd03ff9e08ee18a2beb94c431371a"
},
{
"type": "PACKAGE",
"url": "https://github.com/yawkat/lz4-java"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.2"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "yawkat LZ4 Java: LZ4DecompressorWithLength allocates the unvalidated size from the 4-byte length header, so a 5-byte input triggers a 1 GiB allocation and OutOfMemoryError"
}
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.
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.