Netty CVE-2026-42583

Exploitation requires the target application to use Netty's Lz4FrameDecoder in a server-side ChannelPipeline that processes data from untrusted network sources. Specifically, the application must accept LZ4-compressed frames over TCP or UDP and instantiate the Lz4FrameDecoder handler to decompress incoming data. Most critical for services explicitly designed to handle LZ4-compressed protocols (custom binary APIs, gaming servers, distributed systems using LZ4 for wire compression). Exploitation is limited if: (a) the application uses Netty but does not employ LZ4 compression handlers, (b) LZ4 decoding is restricted to authenticated users or internal-only channels, (c) per-channel or aggregate memory quotas are enforced via Netty configuration or JVM heap limits, or (d) network infrastructure enforces connection rate limits or payload inspection that discards malformed LZ4 frames. No user interaction required - remote unauthenticated exploitation against default configurations of Netty applications exposing Lz4FrameDecoder to untrusted inputs.

Real-world risk is moderate to high for exposed applications but not universally critical. CVSS vector AV:N/AC:L/PR:N/UI:N indicates straightforward remote exploitation without authentication - a single unauthenticated attacker can exhaust server memory by opening concurrent connections and sending 22-byte frames repeatedly. EPSS data not provided, but the low attack complexity and network vector suggest high exploitation feasibility once attackers identify vulnerable endpoints. No CISA KEV listing indicates this is not yet widely exploited in the wild, but the published PoC in GitHub advisory GHSA-mj4r-2hfc-f8p6 lowers the skill barrier to opportunistic attacks. Key risk mitigators: this specifically affects applications that (1) use Netty's Lz4FrameDecoder in server-side pipelines and (2) accept LZ4-compressed data from untrusted network sources. Many Netty deployments use HTTP/2 or custom protocols without LZ4 compression, reducing the attack surface. Applications with per-connection memory limits, rate limiting, or Web Application Firewalls may already have compensating controls. Priority is highest for public-facing services explicitly advertising LZ4 compression support (e.g., custom binary protocols, game servers, IoT gateways) without aggregate memory caps.

An attacker identifies a Java service exposing a Netty-based binary protocol endpoint on TCP port 8080 that accepts LZ4-compressed payloads. The attacker crafts a minimal 22-byte LZ4 frame with a valid magic number, BLOCK_TYPE_COMPRESSED flag, compressedLength of 1 byte, and decompressedLength set to the maximum 32MB (1 << 25). Opening 1,000 concurrent connections and sending this crafted frame on each connection forces the server to allocate 32GB of heap memory (1,000 * 32MB) within seconds, exhausting available RAM and triggering OutOfMemoryError. Publicly available exploit code exists in GitHub advisory GHSA-mj4r-2hfc-f8p6, lowering the barrier to replication.