CVE-2026-42583: Netty Lz4FrameDecoder DoS Vulnerability

CVE-2026-42583 Overview

CVE-2026-42583 is a denial-of-service vulnerability in Netty, an asynchronous event-driven network application framework widely used in Java-based servers and clients. The flaw resides in Lz4FrameDecoder, which pre-allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 decompression executes. A remote attacker needs only a 21-byte header plus minimal compressedLength payload bytes to trigger the full allocation. Versions prior to 4.2.13.Final and 4.1.133.Final are affected. The issue is classified under CWE-400 (Uncontrolled Resource Consumption).

Critical Impact

Unauthenticated remote attackers can force large heap allocations with minimal traffic, leading to memory exhaustion and service disruption.

Affected Products

• Netty versions prior to 4.2.13.Final
• Netty versions prior to 4.1.133.Final
• Applications using Lz4FrameDecoder for LZ4-framed network traffic

Discovery Timeline

• 2026-05-13 - CVE-2026-42583 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42583

Vulnerability Analysis

The vulnerability stems from how Lz4FrameDecoder handles attacker-controlled length fields in LZ4 frame headers. The decoder reads the decompressedLength field from the frame header and immediately allocates a ByteBuf of that size, up to 32 MB per block, before validating the actual compressed payload or performing decompression. An attacker can send a crafted 21-byte LZ4 header that declares a 32 MB decompressed length, accompanied by only the compressedLength payload bytes required by the protocol. When compressedLength == 1, just 22 bytes on the wire trigger a 32 MB heap allocation on the server.

This amplification ratio enables resource exhaustion attacks against any service that wires Lz4FrameDecoder into its Netty pipeline. Repeated requests across multiple connections rapidly exhaust JVM heap and trigger OutOfMemoryError conditions, degrading or terminating the affected process.

Root Cause

The root cause is missing validation between the declared decompressed size and the actual compressed payload size before allocation. The decoder trusts the peer-supplied length field instead of bounding allocation by the available compressed bytes or applying a configurable maximum aligned with realistic traffic.

Attack Vector

Exploitation requires only network reachability to a service that processes LZ4-framed input through Netty. No authentication, user interaction, or prior session state is required. The attacker transmits crafted LZ4 frames with inflated decompressedLength values to consume memory disproportionate to bandwidth expended. See the GitHub Security Advisory GHSA-mj4r-2hfc-f8p6 for protocol-level details.

Detection Methods for CVE-2026-42583

Indicators of Compromise

• Repeated JVM OutOfMemoryError events or sustained heap pressure in Netty-based services accepting LZ4 traffic.
• Inbound TCP flows containing minimally sized LZ4 frames (21–22 bytes) declaring maximal decompressed lengths.
• Connection patterns with high request rates but unusually small payload sizes targeting LZ4-enabled endpoints.

Detection Strategies

• Inspect Netty application logs for allocation failures or garbage collection storms correlated with external traffic spikes.
• Deploy network monitoring rules that flag LZ4 frame headers whose declared decompressed length is disproportionate to the observed compressed payload.
• Audit application dependencies to identify services bundling vulnerable Netty versions and exposing Lz4FrameDecoder to untrusted peers.

Monitoring Recommendations

• Track JVM heap utilization, GC frequency, and direct buffer allocations on services using Netty.
• Alert on abnormal connection-to-payload ratios where many small inbound frames precede memory pressure.
• Correlate Netty pipeline exceptions with upstream client IPs to identify potential abuse sources.

How to Mitigate CVE-2026-42583

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or 4.1.133.Final immediately across all affected services.
• Inventory transitive dependencies in Java applications to surface vulnerable Netty versions bundled by frameworks.
• Restrict exposure of LZ4-decoding endpoints to trusted networks until patching is complete.

Patch Information

The vulnerability is fixed in Netty 4.2.13.Final and 4.1.133.Final. Both releases bound allocation based on the actual compressed payload size, preventing peer-controlled inflation of the initial ByteBuf. Refer to the Netty GHSA-mj4r-2hfc-f8p6 advisory for release artifacts and verification.

Workarounds

• Remove Lz4FrameDecoder from Netty pipelines that do not require LZ4 framing.
• Place rate limits and connection caps in front of Netty services to constrain memory amplification by any single peer.
• Apply upstream proxy controls that reject undersized frames declaring maximum decompressed lengths.

# Maven dependency upgrade example
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.1.133.Final
mvn dependency:tree | grep netty