{"id":"CVE-2026-106452","aliases":["DEBIAN-CVE-2026-106452","EUVD-2026-93871","GHSA-4v53-57pg-c464","UBUNTU-CVE-2026-106452"],"status":"published","title":"yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00454,"percentile":0.39866,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-789"],"published":"2026-10-06T19:52:37Z","modified":"2026-10-28T10:51:03Z","fixes":[{"ecosystem":"Maven","package":"at.yawk.lz4:lz4-java","fixed_in":["1.11.2"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"lz4-java","fixed_in":["1.11.2+ds1-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Maven","package":"at.yawk.lz4:lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.11.1"},{"fixed":"1.11.2"}]}]},{"source":"ghsa","ecosystem":"Maven","package":"org.lz4:lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.8.1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.11.2+ds1-1","1.11.2+ds1-2","1.11.2+ds1-3","1.8.0-3","1.8.0-4"]},{"source":"osv","ecosystem":"Debian:13","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.11.2+ds1-1","1.11.2+ds1-2","1.11.2+ds1-3","1.8.0-4"]},{"source":"osv","ecosystem":"Debian:14","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.2+ds1-1"}]}],"versions":["1.8.0-4"]},{"source":"osv","ecosystem":"Maven","package":"at.yawk.lz4:lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.2"}]}],"versions":["1.10.0","1.10.1","1.10.2","1.10.3","1.10.4","1.11.0","1.11.1","1.8.1","1.9.0"]},{"source":"osv","ecosystem":"Maven","package":"org.lz4:lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.8.1"}]}],"versions":["1.4","1.4.0","1.4.1","1.5.0","1.5.1","1.6.0","1.7.0","1.7.1","1.8.0","1.8.1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.5.1-2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.5.1-3build1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.8.0-3","1.8.0-4","1.8.0-4build1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.8.0-4build2"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"lz4-java","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.8.0-4build1","1.8.0-4build2"]}],"products":[{"vendor":"yawkat","product":"lz4-java"}],"references":[{"url":"https://github.com/yawkat/lz4-java/security/advisories/GHSA-4v53-57pg-c464","tags":["x_refsource_CONFIRM","advisory","web","report"]},{"url":"https://github.com/yawkat/lz4-java/commit/bb83dd16163cdb71231af06b0a5651881148a634","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/yawkat/lz4-java/releases/tag/v1.11.2","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-106452","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-4v53-57pg-c464"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/106xxx/CVE-2026-106452.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-106452","tags":["advisory"]},{"url":"https://github.com/yawkat/lz4-java","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-106452","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-106452","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-106452","title":"yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T19:52:37.818Z","modified":"2026-10-07T10:45:18.01Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T14:20:04.463704Z"}],"euvd":[{"id":"EUVD-2026-93871","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T19:52:37Z","modified":"2026-10-07T10:45:18Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T17:27:35.509652Z"}],"ghsa":[{"id":"GHSA-4v53-57pg-c464","title":"yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header","description":"### Summary\n\n`LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap.\n\n### Details\n\nIn `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation:\n\n```java\ncase COMPRESSION_METHOD_LZ4:\n  if (compressedBuffer.length \u003c compressedLen) {\n    compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)];\n  }\n  readFully(compressedBuffer, compressedLen);\n```\n\nThe paired `LZ4BlockOutputStream` never emits such a block. If compression is not smaller than the original block, it writes the block as RAW:\n\n```java\nif (compressedLength \u003e= o) {\n  compressMethod = COMPRESSION_METHOD_RAW;\n  compressedLength = o;\n} else {\n  compressMethod = COMPRESSION_METHOD_LZ4;\n}\n```\n\nExisting readers generally accept noncanonical LZ4-method blocks where `compressedLen \u003e= originalLen`, but no canonical writer found produces them.\n\n### Impact\n\nApplications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputStream` can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload.\n\n### Patch\n\nAs of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new `acceptOversizedBlocks` flag to restore the old behavior, but this reintroduces the DoS vector.","status":"published","published":"2026-10-07T16:17:50Z","modified":"2026-10-07T16:17:51Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T14:41:28.013673Z"}],"nvd":[{"id":"CVE-2026-106452","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T20:17:27.317Z","modified":"2026-10-07T13:58:29.527Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T14:12:54.809359Z"}],"osv":[{"id":"CVE-2026-106452","title":"yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T19:52:37.818Z","modified":"2026-10-28T10:51:03.2399319Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T15:44:54.583213Z"},{"id":"DEBIAN-CVE-2026-106452","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T20:17:27.317Z","modified":"2026-10-08T09:47:37.146067173Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:45:49.381767Z"},{"id":"GHSA-4v53-57pg-c464","title":"yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header","description":"### Summary\n\n`LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap.\n\n### Details\n\nIn `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation:\n\n```java\ncase COMPRESSION_METHOD_LZ4:\n  if (compressedBuffer.length \u003c compressedLen) {\n    compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)];\n  }\n  readFully(compressedBuffer, compressedLen);\n```\n\nThe paired `LZ4BlockOutputStream` never emits such a block. If compression is not smaller than the original block, it writes the block as RAW:\n\n```java\nif (compressedLength \u003e= o) {\n  compressMethod = COMPRESSION_METHOD_RAW;\n  compressedLength = o;\n} else {\n  compressMethod = COMPRESSION_METHOD_LZ4;\n}\n```\n\nExisting readers generally accept noncanonical LZ4-method blocks where `compressedLen \u003e= originalLen`, but no canonical writer found produces them.\n\n### Impact\n\nApplications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputStream` can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload.\n\n### Patch\n\nAs of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new `acceptOversizedBlocks` flag to restore the old behavior, but this reintroduces the DoS vector.","status":"published","published":"2026-10-07T16:17:50Z","modified":"2026-10-07T16:30:04.845963758Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-789"],"updated_at":"2026-11-02T15:46:37.528068Z"},{"id":"UBUNTU-CVE-2026-106452","description":"yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.","status":"published","published":"2026-10-06T20:17:00Z","modified":"2026-10-17T12:58:01.535974885Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T16:55:59.130573Z"}]}}