LZ4 Java CVE-2026-106450

The application must decode attacker-controlled LZ4 data using net.jpountz.lz4.LZ4FrameInputStream in its DEFAULT concatenated-frame mode; the attacker crafts a stream of many minimal empty maximum-block-size frames so that readHeader() repeatedly allocates two 4 MiB block buffers. Key limiting factor: readSingleFrame mode is explicitly NOT affected, so applications that construct the stream in single-frame mode are not vulnerable. Note that decompressed-size/output limits do NOT mitigate this because the stream yields no decompressed output while still consuming CPU and GC time. No authentication, user interaction, or non-default configuration is required for the default-mode case; exploitation only requires that untrusted LZ4 frame input reach this decoder.

This is a genuine but moderate-severity denial-of-service issue, not a critical priority. The vendor-assigned CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, score 5.3) is internally consistent with the description and with CWE-770 (allocation of resources without limits): a remote, unauthenticated attacker with low complexity can cause availability-only impact via roughly 8 MiB of heap allocation and GC pressure per 11 input bytes, with no confidentiality or integrity effect. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so exploitation-probability and active-exploitation signals cannot be evaluated - per precedent rules this is treated as 'no public exploit identified at time of analysis.' The amplification factor is high and the fix commit is public (which lowers the barrier to building a trigger), but real-world risk is gated by whether a given application actually decodes untrusted LZ4 frame data through LZ4FrameInputStream in the default concatenated-frame mode. One nuance to verify: the description notes that decompressed-size limits do NOT mitigate this because the stream produces no decompressed output while still consuming CPU/GC, so operators relying on output-size caps as a defense should not assume they are protected.

An attacker supplies a malicious LZ4 stream - for example as an uploaded file, API payload, or message consumed by a backend service - to an application that decodes it with LZ4FrameInputStream in the default concatenated-frame mode. The stream contains many minimal empty frames, each forcing allocation of two 4 MiB block buffers, so a tiny input (about 11 bytes per frame) drives roughly 8 MiB of allocation and sustained GC activity, degrading or exhausting the JVM. No public exploit code was identified at time of analysis, though the public fix commit reveals the triggering frame structure.