CVE-2026-42583

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Netty's Lz4FrameDecoder. Before Netty 4.2.13.Final and 4.1.133.Final, the decoder trusts the decompressed length value in an LZ4 frame and allocates a ByteBuf of that declared size before decompression occurs. An unauthenticated network peer can send a very small malformed or adversarial LZ4 frame, as little as a 21-byte header plus minimal compressed payload, that declares a decompressed block size of up to 32 MB. Repeating this across one or many connections can rapidly exhaust heap memory, direct memory, allocator arenas, or garbage-collection capacity, causing application stalls, connection failures, OutOfMemoryError conditions, process crashes, or container restarts. Confidentiality and integrity are not directly affected, but availability can be severely impacted.

Why it matters to the business

Applications, APIs, gateways, brokers, and services that use affected Netty versions with LZ4 frame decoding exposed to untrusted peers can be forced offline or made unstable with low attacker effort. The main operational risk is service disruption: failed customer requests, degraded throughput, cascading failures in dependent services, autoscaling churn, and incident response costs. The vulnerability has a high availability CVSS impact but currently low EPSS, no known CISA KEV listing, no known ransomware association, and no public exploit maturity reported in the provided data; however, the issue is easy to trigger where the vulnerable decoder is reachable, so exposed internet-facing or high-volume internal services should still be prioritized.

How an attack unfolds

An attacker first identifies a network service or protocol path backed by Netty that accepts LZ4-framed compressed input and routes it through Lz4FrameDecoder. The attacker then establishes one or more connections and sends crafted LZ4 frame data containing a valid-looking header that advertises a large decompressedLength, up to the maximum block size, while providing only a tiny compressed payload. In vulnerable versions, Netty allocates a ByteBuf based on the attacker-controlled decompressedLength before validating or performing decompression. By repeating these frames, opening concurrent connections, or pacing requests to bypass simple rate limits, the attacker can force repeated large memory allocations. The target may experience allocator pressure, excessive garbage collection, direct memory exhaustion, heap exhaustion, request timeouts, and ultimately process termination or service unavailability.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later for the 4.2.x line, or 4.1.133.Final or later for the 4.1.x line. Because Netty is commonly included transitively through application frameworks, API gateways, RPC stacks, messaging clients, and reactive web runtimes, inspect dependency trees and packaged artifacts rather than only direct dependencies. If immediate upgrade is not possible, mitigate by disabling LZ4 frame decoding for untrusted inputs, restricting access to affected endpoints, enforcing strict connection and request rate limits, limiting maximum accepted frame sizes before Netty decompression, reducing per-client concurrency, and using process/container memory limits with supervised restarts. These mitigations reduce blast radius but should not be considered substitutes for upgrading.

How to confirm the fix worked

Confirm that all deployed applications and packaged artifacts resolve Netty to 4.2.13.Final or later, or 4.1.133.Final or later. Validate both build-time and runtime classpaths, including shaded JARs, fat JARs, containers, plugins, vendor appliances, and framework-managed dependencies. Dependency tools such as Maven dependency:tree, Gradle dependencies, SBOM scanners, container image scanners, and runtime JAR inspection can be used to verify versions. Where safe and authorized, perform a negative test against a non-production instance by sending malformed or oversized LZ4-framed input and confirming the service rejects it without large memory growth, OutOfMemoryError, process restart, or sustained garbage-collection pressure. Monitor memory allocation, direct memory, heap usage, request failures, and restart counters during validation.

Typical attack path

1. Discover a Netty-based service that accepts LZ4-framed compressed traffic from untrusted clients.
2. Confirm that the reachable protocol path invokes io.netty.handler.codec.compression.Lz4FrameDecoder.
3. Open one or more network connections to the service.
4. Send crafted LZ4 frame headers declaring a large decompressed length with a very small compressed payload.
5. Repeat the malformed frames or increase concurrency to amplify memory allocation pressure.
6. Cause allocator exhaustion, garbage-collection pressure, OutOfMemoryError, process crash, container restart, or sustained service degradation.

How to detect it

To determine whether exploitation may have already occurred, review application logs, JVM logs, container logs, load balancer logs, reverse proxy logs, and infrastructure monitoring for unexplained memory spikes, direct memory exhaustion, garbage-collection storms, process crashes, pod restarts, or bursts of failed connections against services that accept LZ4-compressed input. Focus on time windows with sudden increases in 5xx responses, connection resets, request timeouts, or restart loops without corresponding traffic volume increases. Search stack traces and crash reports for Netty compression classes, especially Lz4FrameDecoder, ByteBuf allocation failures, OutOfMemoryError, Direct buffer memory errors, and allocator exceptions. Network-level evidence may show many short-lived connections or small inbound payloads preceding large memory growth, though crafted frames may not leave a unique signature unless packet capture or protocol-aware logging is available. Because this is a denial-of-service issue rather than code execution, expected artifacts are availability symptoms, decoder errors, allocation failures, and source IPs repeatedly sending malformed or compression-related traffic rather than dropped malware files or persistence mechanisms.

• io.netty.handler.codec.compression.Lz4FrameDecoder
• Lz4FrameDecoder
• java.lang.OutOfMemoryError: Direct buffer memory
• java.lang.OutOfMemoryError: Java heap space
• io.netty.buffer.AbstractByteBufAllocator
• io.netty.util.internal.OutOfDirectMemoryError
• failed to allocate
• Cannot reserve memory
• GC overhead limit exceeded
• OutOfMemoryError
• direct buffer memory
• Compressed length
• decompressedLength
• LZ4
• LZ4 frame
• pod restarted
• CrashLoopBackOff
• OOMKilled

What your security team should do

• Inventory internet-facing and partner-facing services that use Netty and determine whether Lz4FrameDecoder is reachable from untrusted clients.
• Patch affected applications to Netty 4.2.13.Final or later, or 4.1.133.Final or later, prioritizing externally reachable and business-critical services.
• Review dependency trees and SBOMs for transitive Netty usage, including shaded or bundled copies in application artifacts and third-party products.
• Temporarily disable LZ4 compression support or block untrusted compressed traffic on affected protocol paths until upgrades are complete.
• Add rate limits, connection limits, request-size controls, and memory safeguards for exposed Netty services to reduce denial-of-service blast radius.
• Create monitoring and alerting for sudden direct memory growth, heap exhaustion, elevated garbage collection, increased 5xx errors, connection resets, pod or process restarts, and OutOfMemoryError events.
• Search recent logs and crash artifacts for evidence of repeated LZ4 decoder failures, memory exhaustion, or unexplained service restarts around externally reachable Netty services.
• Track vendor advisories for products that embed Netty and apply vendor-provided updates when direct dependency upgrades are not available.