CVE-2026-106450: Denial of Service via Eager Resource Allocation in lz4-java LZ4FrameInputStream

The library lz4-java is a widely utilized compression library for Java, wrapping both JNI and native Java implementations of the LZ4 algorithm. Within this library, the class net.jpountz.lz4.LZ4FrameInputStream is responsible for decompressing streams formatted according to the LZ4 Frame Format specification. This specification supports concatenated streams, meaning a single raw input stream can consist of multiple independent LZ4 frames appended to each other, which the reader parses sequentially.\n\nPrior to version 1.11.4, a critical memory allocation vulnerability existed in the frame header parsing logic. The stream implementation eagerly allocated large internal byte buffers for each frame based on metadata declarations in the header, rather than when actual payload data blocks were read. An attacker can exploit this behavior by submitting a continuous stream of minimal, empty frames, causing the Java Virtual Machine (JVM) to spend its resources allocating and reclaiming memory.\n\nThis flaw is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). It presents a significant Denial of Service (DoS) attack surface for any network-exposed application that ingests and decompresses user-supplied LZ4 data streams, such as file upload endpoints, log collectors, or message queue consumers. Because the empty frames do not produce decompressed output bytes, conventional decompressed-payload threshold checks cannot detect or restrict this CPU and memory consumption.

The root cause of CVE-2026-106450 lies in the timing and design of memory allocation within the LZ4FrameInputStream.readHeader() method. The LZ4 Frame format begins with a Frame Descriptor, which contains a Block Descriptor (BD) byte. This BD byte indicates the maximum size of data blocks contained within that frame. This value can specify block sizes up to 4 MiB (e.g., when the BD flag is set to 7).\n\nIn the vulnerable implementation, whenever a frame boundary was crossed, the readHeader() method parsed this BD byte and immediately allocated two byte arrays of this maximum block size: compressedBuffer and rawBuffer. Together, these buffers demanded up to 8 MiB of heap memory. This allocation occurred eagerly, prior to confirming whether the frame actually contained any data blocks.\n\nAn attacker can construct a valid, empty LZ4 frame that is only 11 bytes long. This minimal frame contains a magic number, a frame descriptor byte (FLG), a block descriptor byte (BD) claiming a 4 MiB block size, a header checksum byte (HC), and a 4-byte end-of-stream marker (EndMark) set to 0x00000000. When processing a stream of these empty frames, the stream's state machine repeatedly discards the previous frame's buffers and allocates a new set of 8 MiB buffers for each 11 bytes of input, leading to a memory allocation amplification factor of approximately 762,600 to 1.\n\nThis creates severe Garbage Collection (GC) pressure and high CPU load on the JVM. The CPU is consumed by the zero-initialization of large byte arrays, while the Garbage Collector is forced into high-frequency, stop-the-world cycles to reclaim the rapidly discarded arrays.\n\nmermaid\ngraph LR\n A["11-Byte Input Frame"] --> B["Parser reads BD Byte (0x70)"]\n B --> C["Eagerly Allocates 8 MiB Heap Space"]\n C --> D["Parser reads EndMark (0x00000000)"]\n D --> E["Frame Concludes (0 bytes output)"]\n E --> F["Buffers Discarded to GC"]\n F --> A\n

The key fix in commit 2acc0ec1ead226145c62a817c18c8ed49233a283 changes buffer initialization from eager allocation during header parsing to lazy allocation during data block reading. Additionally, the new logic caches and reuses the buffers instead of re-allocating them on every new frame boundary.\n\nBelow is the comparison of the vulnerable code versus the patched code within net.jpountz.lz4.LZ4FrameInputStream.java:\n\njava\n// VULNERABLE CODE (Pre-1.11.4)\nprivate void readHeader() throws IOException {\n // ... parsing logic ...\n maxBlockSize = frameInfo.getBD().getBlockMaximumSize();\n compressedBuffer = new byte[maxBlockSize]; // Eager allocation\n rawBuffer = new byte[maxBlockSize]; // Eager allocation\n buffer = ByteBuffer.wrap(rawBuffer);\n buffer.limit(0);\n firstFrameHeaderRead = true;\n anyFrameRead = true;\n}\n\n\njava\n// PATCHED CODE (1.11.4+)\nprivate void readHeader() throws IOException {\n // ... parsing logic ...\n maxBlockSize = frameInfo.getBD().getBlockMaximumSize();\n // Allocations removed from readHeader()\n buffer.limit(0);\n firstFrameHeaderRead = true;\n anyFrameRead = true;\n}\n\n\nIn the patched code, the allocations are moved to the block-reading routine, readBlock(), and are guarded by checks to ensure buffers are only allocated when required and are reused if they are already large enough:\n\njava\n// LAZY ALLOCATION AND REUSE IN readBlock()\nprivate void readBlock() throws IOException {\n // ... state checks ...\n if (rawBuffer == null || rawBuffer.length < maxBlockSize) {\n rawBuffer = new byte[maxBlockSize];\n buffer = ByteBuffer.wrap(rawBuffer);\n buffer.limit(0); // Protect contents if block read fails\n }\n final byte[] tmpBuffer;\n if (compressed) {\n if (compressedBuffer == null || compressedBuffer.length < maxBlockSize) {\n compressedBuffer = new byte[maxBlockSize];\n }\n tmpBuffer = compressedBuffer;\n } else {\n tmpBuffer = rawBuffer;\n }\n // ... read logic ...\n}\n\n\nThis modification guarantees that if an empty frame containing no blocks is processed, no heap buffers are allocated. Furthermore, the reuse logic ensures that even for streams with many populated frames, the allocations scale with the maximum block size seen so far, rather than with the total count of frames.

An attacker can exploit this vulnerability by establishing a connection to a vulnerable service and transmitting a continuous stream of serialized empty frames. Because the vulnerability lies within a stream-handling class, the entire payload does not need to be buffered in memory or saved to disk before decompression begins; the JVM will process each 11-byte frame on-the-fly as it is received from the network socket.\n\nTo construct the exploit payload, the attacker must generate a series of valid LZ4 frame headers that request the maximum block size without supplying any data blocks. Below is a conceptual representation of the structure of a single 11-byte attacking frame:\n\n* Magic Number (4 bytes): 0x184D2204 (LZ4 frame identifier in little-endian format)\n* FLG Byte (1 byte): 0x40 (Specifies frame version 01 and independent blocks)\n* BD Byte (1 byte): 0x70 (Requests the maximum 4 MiB block size)\n* HC Byte (1 byte): 0x6D (A pre-calculated xxHash checksum validating the FLG and BD fields)\n* EndMark (4 bytes): 0x00000000 (Indicates the frame contains zero data blocks)\n\nAn attacker can concatenate thousands of these 11-byte blocks into a single payload file or stream. When sent to a vulnerable application, this payload results in sustained CPU exhaustion and memory instability, disabling the service for legitimate users. Because the decompressed length of the stream is zero, security layers or filters checking the ratio between compressed and decompressed size (e.g., zip-bomb mitigations) will not trigger, as no uncompressed data is ever emitted.

The impact of CVE-2026-106450 is a high-availability compromise, leading to a complete Denial of Service (DoS) of the affected Java process. Because the processing of LZ4 streams often occurs in incoming request threads (such as HTTP handlers or API endpoints), exhausting the CPU and triggering continuous garbage collection cycles degrades the performance of the entire JVM, affecting all hosted services.\n\nThis vulnerability has been assigned a CVSS v3.1 score of 5.3 (Medium), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. While the vector classifies the availability impact as low ("A:L") due to standard CVSS scoring rubrics for general library dependencies, the actual impact on real-world deployments is often a complete service failure. In environments where JVM memory parameters (such as -Xmx) are tightly bounded, the high allocation rate can trigger an OutOfMemoryError (OOM) and crash the container.\n\nFurthermore, because the attack requires very low bandwidth—a continuous stream of a few kilobytes per second can force gigabytes of heap allocations—it is highly asymmetric. It bypasses many standard rate-limiting systems because the request size is extremely small and does not violate typical payload size limitations.

The primary remediation strategy is upgrading the dependency lz4-java to version 1.11.4 or higher. This release addresses the vulnerability by implementing lazy allocation and buffer caching as detailed in the code analysis.\n\nFor environments where immediate upgrading is not possible, the following temporary mitigations should be considered:\n\n* Apply Input Rate Limits: Restrict the network throughput on endpoints known to accept LZ4 streams. Limiting incoming data transfer rate minimizes the frequency of allocation cycles.\n* Limit Concurrent Decompression Tasks: Cap the number of concurrent worker threads or asynchronous tasks that process compressed input. This bounds the total potential memory allocation overhead at any given moment.\n* Implement Connection Timeouts: Set aggressive read and idle timeouts on incoming connections to prevent slow-rate streaming attacks where an attacker slowly feeds empty frames over a prolonged period.\n\nAdditionally, developers should note a residual risk in the patched version: because the allocated buffers are cached and never shrunk, a stream that processes a single large block (e.g., 4 MiB) will retain that memory footprint for its entire lifetime. Applications should therefore avoid maintaining long-lived, persistent decompression streams for untrusted clients to prevent memory-pinning attacks.