yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs
### Summary `LZ4FrameInputStream` allocates two new buffers of the frame's maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes. ### Details In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`: ```java maxBlockSize = frameInfo.getBD().getBlockMaximumSize(); compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions rawBuffer = new byte[maxBlockSize]; buffer = ByteBuffer.wrap(rawBuffer); ``` This runs for every frame, and the previous frame's arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte. ### Impact Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits do not h
- Products
- at.yawk.lz4:lz4-java, org.lz4:lz4-java
- Affected versions
- 1.10.0, 1.10.1, 1.10.2, 1.10.3, 1.10.4, 1.11.0, 1.11.1, 1.11.2, 1.11.3, 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, 1.9.0
- Fixed versions
- 1.11.4
- CVEs
- CVE-2026-106450
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 28 Oct 2026, 08:48 UTC · Revision 1
Source evidence
yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs
core-osv · Original sourcePublished 7 Oct 2026, 20:35 UTC
### Summary `LZ4FrameInputStream` allocates two new buffers of the frame's maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes. ### Details In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`: ```java maxBlockSize = frameInfo.getBD().getBlockMaximumSize(); compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions rawBuffer = new byte[maxBlockSize]; buffer = ByteBuffer.wrap(rawBuffer); ``` This runs for every frame, and the previous frame's arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte. ### Impact Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits do not h
osv:GHSA-gm45-99xc-r7wv
at.yawk.lz4:lz4-java
Fixed versions: 1.11.4
org.lz4:lz4-java
Fixed versions: Not specified
Complete source record
{
"id": "35c2f3b9286fb6d78c240cc4ac5bd17f89cab05b4699e09761e54c84f289e596",
"url": "https://osv.dev/vulnerability/GHSA-gm45-99xc-r7wv",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs",
"summary": "### Summary `LZ4FrameInputStream` allocates two new buffers of the frame's maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes. ### Details In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`: ```java maxBlockSize = frameInfo.getBD().getBlockMaximumSize(); compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions rawBuffer = new byte[maxBlockSize]; buffer = ByteBuffer.wrap(rawBuffer); ``` This runs for every frame, and the previous frame's arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte. ### Impact Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits do not h",
"evidence": "osv:GHSA-gm45-99xc-r7wv",
"products": [
{
"name": {
"value": "at.yawk.lz4:lz4-java",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "1.11.4",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": [
{
"value": "1.10.0",
"evidence": "/affected/0/versions"
},
{
"value": "1.10.1",
"evidence": "/affected/0/versions"
},
{
"value": "1.10.2",
"evidence": "/affected/0/versions"
},
{
"value": "1.10.3",
"evidence": "/affected/0/versions"
},
{
"value": "1.10.4",
"evidence": "/affected/0/versions"
},
{
"value": "1.11.0",
"evidence": "/affected/0/versions"
},
{
"value": "1.11.1",
"evidence": "/affected/0/versions"
},
{
"value": "1.11.2",
"evidence": "/affected/0/versions"
},
{
"value": "1.11.3",
"evidence": "/affected/0/versions"
},
{
"value": "1.8.1",
"evidence": "/affected/0/versions"
},
{
"value": "1.9.0",
"evidence": "/affected/0/versions"
}
]
},
{
"name": {
"value": "org.lz4:lz4-java",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": [
{
"value": "1.4",
"evidence": "/affected/1/versions"
},
{
"value": "1.4.0",
"evidence": "/affected/1/versions"
},
{
"value": "1.4.1",
"evidence": "/affected/1/versions"
},
{
"value": "1.5.0",
"evidence": "/affected/1/versions"
},
{
"value": "1.5.1",
"evidence": "/affected/1/versions"
},
{
"value": "1.6.0",
"evidence": "/affected/1/versions"
},
{
"value": "1.7.0",
"evidence": "/affected/1/versions"
},
{
"value": "1.7.1",
"evidence": "/affected/1/versions"
},
{
"value": "1.8.0",
"evidence": "/affected/1/versions"
},
{
"value": "1.8.1",
"evidence": "/affected/1/versions"
}
]
}
],
"severity": "medium",
"structured": {
"id": "GHSA-gm45-99xc-r7wv",
"aliases": [
"CVE-2026-106450",
"GHSA-gm45-99xc-r7wv"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.4"
}
]
}
],
"package": {
"name": "at.yawk.lz4:lz4-java",
"purl": "pkg:maven/at.yawk.lz4/lz4-java",
"ecosystem": "Maven"
},
"versions": [
"1.10.0",
"1.10.1",
"1.10.2",
"1.10.3",
"1.10.4",
"1.11.0",
"1.11.1",
"1.11.2",
"1.11.3",
"1.8.1",
"1.9.0"
],
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-gm45-99xc-r7wv/GHSA-gm45-99xc-r7wv.json",
"last_known_affected_version_range": "<= 1.11.3"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
]
}
],
"package": {
"name": "org.lz4:lz4-java",
"purl": "pkg:maven/org.lz4/lz4-java",
"ecosystem": "Maven"
},
"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"
],
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-gm45-99xc-r7wv/GHSA-gm45-99xc-r7wv.json"
}
}
],
"modified": "2026-10-07T20:45:05.906321924Z",
"provider": "osv",
"references": [
"https://github.com/yawkat/lz4-java/security/advisories/GHSA-gm45-99xc-r7wv",
"https://nvd.nist.gov/vuln/detail/CVE-2026-106450",
"https://github.com/yawkat/lz4-java/commit/2acc0ec1ead226145c62a817c18c8ed49233a283",
"https://github.com/yawkat/lz4-java",
"https://github.com/yawkat/lz4-java/releases/tag/v1.11.4"
],
"provider_metadata": {
"cwe_ids": [
"CWE-770"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": "2026-10-06T20:17:27Z",
"github_reviewed_at": "2026-10-07T20:35:40Z"
}
},
"related_cves": [
{
"value": "CVE-2026-106450",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 97267,
"published_at": "2026-10-07T20:35:40+00:00"
}