GHSA-343H-94H5-C4WR
Vulnerability from github – Published: 2026-10-07 20:35 – Updated: 2026-10-07 20:35Summary
When LZ4BlockInputStream is configured with stopOnEmptyBlock = false (the mode for reading concatenated block streams), it handles each empty block by calling refill() recursively. A long run of empty blocks exhausts the thread stack and throws StackOverflowError out of read() or skip().
Details
In net.jpountz.lz4.LZ4BlockInputStream.refill():
if (originalLen == 0 && compressedLen == 0) {
if (check != 0) {
throw new IOException("Stream is corrupted");
}
if (!stopOnEmptyBlock) {
refill();
} else {
finished = true;
}
return;
}
Each well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw StackOverflowError. StackOverflowError is an Error, not an IOException, so callers that only handle I/O errors for corrupt input don't catch it.
Impact
Applications that decode attacker-controlled LZ4Block streams with LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false) or the deprecated LZ4BlockInputStream(InputStream, boolean) constructor can have the decoding thread fail with StackOverflowError. The default configuration (stopOnEmptyBlock = true) is not affected. There is no memory corruption. Availability impact only.
Patch
Fixed in lz4-java 1.11.4. Empty blocks are now skipped in a loop instead of by recursion, so any number of consecutive empty blocks uses constant stack space.
For older versions, the workaround is to use the default stopOnEmptyBlock = true for untrusted input, or catch StackOverflowError around the read loop.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.3"
},
"package": {
"ecosystem": "Maven",
"name": "at.yawk.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106449"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:35:46Z",
"nvd_published_at": "2026-10-06T20:17:26Z",
"severity": "LOW"
},
"details": "### Summary\n\nWhen `LZ4BlockInputStream` is configured with `stopOnEmptyBlock = false` (the mode for reading concatenated block streams), it handles each empty block by calling `refill()` recursively. A long run of empty blocks exhausts the thread stack and throws `StackOverflowError` out of `read()` or `skip()`.\n\n### Details\n\nIn `net.jpountz.lz4.LZ4BlockInputStream.refill()`:\n\n```java\nif (originalLen == 0 \u0026\u0026 compressedLen == 0) {\n if (check != 0) {\n throw new IOException(\"Stream is corrupted\");\n }\n if (!stopOnEmptyBlock) {\n refill();\n } else {\n finished = true;\n }\n return;\n}\n```\n\nEach well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw `StackOverflowError`. `StackOverflowError` is an `Error`, not an `IOException`, so callers that only handle I/O errors for corrupt input don\u0027t catch it.\n\n### Impact\n\nApplications that decode attacker-controlled `LZ4Block` streams with `LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false)` or the deprecated `LZ4BlockInputStream(InputStream, boolean)` constructor can have the decoding thread fail with `StackOverflowError`. The default configuration (`stopOnEmptyBlock = true`) is not affected. There is no memory corruption. Availability impact only.\n\n### Patch\n\nFixed in lz4-java 1.11.4. Empty blocks are now skipped in a loop instead of by recursion, so any number of consecutive empty blocks uses constant stack space.\n\nFor older versions, the workaround is to use the default `stopOnEmptyBlock = true` for untrusted input, or catch `StackOverflowError` around the read loop.",
"id": "GHSA-343h-94h5-c4wr",
"modified": "2026-10-07T20:35:46Z",
"published": "2026-10-07T20:35:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-343h-94h5-c4wr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106449"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/commit/c8ebf97d504fb34434fda46fc761e8202570e0d8"
},
{
"type": "PACKAGE",
"url": "https://github.com/yawkat/lz4-java"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "yawkat LZ4 Java: LZ4BlockInputStream with stopOnEmptyBlock=false recurses once per empty block, causing StackOverflowError"
}
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.