CVE-2026-59901

What it actually does

Netty versions prior to 4.1.136.Final and 4.2.16.Final contain a denial-of-service flaw in the Bzip2Decoder compression handler. A malformed bzip2 stream can trigger an infinite loop in the run-length encoding state machine inside Bzip2BlockDecompressor.read(), causing a Netty event-loop thread to become permanently occupied. Because Netty event loops multiplex many connections, pinning one or more event-loop threads can degrade or halt request processing for affected services without requiring authentication or user interaction.

Why it matters to the business

Services that use Netty to decode attacker-controlled bzip2-compressed input may become slow, unresponsive, or unavailable after receiving a specially crafted compressed stream. The issue is network-reachable, low-complexity, and unauthenticated, but current public exploitation signals are low: EPSS is 0.263%, it is not listed in CISA KEV, it is not marked as ransomware-used, and no exploit maturity is reported. Organizations should still prioritize remediation for internet-facing or high-throughput Netty-based services because availability impact is high and the vulnerable component is common in Java network stacks.

How an attack unfolds

An attacker first identifies an application endpoint, protocol handler, gateway, or service path that accepts compressed data and routes it through Netty's Bzip2Decoder. The attacker then sends a malformed bzip2 stream crafted to exercise the vulnerable run-length decoding logic. When Netty attempts to decompress the stream, Bzip2BlockDecompressor.read() fails to make progress and the event-loop thread remains stuck in an infinite loop. That event loop can no longer process other I/O events, timers, or connections assigned to it. Repeating the request or opening multiple connections can consume additional event-loop threads, leading to degraded throughput or a full service outage.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later for the 4.1.x line, or 4.2.16.Final or later for the 4.2.x line. Review both direct and transitive Java dependencies because Netty is often included through frameworks, SDKs, gateways, messaging clients, and RPC libraries. If immediate upgrade is not possible, disable bzip2 decoding for untrusted input, reject bzip2-compressed requests at the edge, enforce strict request size and time limits, isolate decompression from event-loop threads where feasible, and apply rate limiting for endpoints that accept compressed payloads. Rebuild and redeploy affected applications after dependency updates; simply updating a shared repository is not sufficient unless the running artifact includes the fixed Netty version.

How to confirm the fix worked

Confirm the deployed application artifact resolves Netty modules to 4.1.136.Final or later, or 4.2.16.Final or later, especially netty-codec and any module providing io.netty.handler.codec.compression.Bzip2Decoder. Use dependency tooling such as Maven dependency:tree, Gradle dependencies, SBOM scanners, or container image scanners to verify there are no older Netty jars packaged in the runtime image. Validate that endpoints no longer route untrusted bzip2 streams through vulnerable code, or that bzip2 decoding is disabled where not required. In staging, perform negative testing with malformed compressed input and verify the service returns an error, closes the connection, or times out safely without sustained event-loop CPU consumption or stuck event-loop stack traces.

Typical attack path

1. Discover a Netty-based service or application path that accepts bzip2-compressed input.
2. Confirm that inbound data is decoded through Netty's Bzip2Decoder compression codec.
3. Send a malformed bzip2 stream to the reachable endpoint or protocol handler.
4. Trigger the infinite loop in Bzip2BlockDecompressor.read() during decompression.
5. Keep the affected connection open or repeat the request to pin one or more Netty event-loop threads.
6. Cause elevated CPU usage, stalled I/O processing, request timeouts, connection backlog growth, or service unavailability.

How to detect it

To assess possible prior exploitation, review application logs, JVM logs, observability traces, load balancer metrics, and host telemetry for unexplained availability degradation affecting Netty-based services that process bzip2 input. Look for sudden request timeouts, connection resets, event-loop blocked warnings, sustained high CPU with low request throughput, increased queue depth, and services requiring restart to recover. Collect historical JVM thread dumps, crash diagnostics, profiler samples, or support bundles if available; a strong forensic signal is one or more Netty event-loop threads repeatedly or permanently showing stack frames in io.netty.handler.codec.compression.Bzip2BlockDecompressor.read or Bzip2Decoder decode paths. Network telemetry may show inbound payloads beginning with the bzip2 magic bytes BZh immediately before service degradation. Because this is a denial-of-service issue rather than code execution, durable host artifacts may be limited; absence of file-system changes does not rule out exploitation.

• io.netty.handler.codec.compression.Bzip2Decoder
• io.netty.handler.codec.compression.Bzip2BlockDecompressor.read
• Bzip2BlockDecompressor.read
• Bzip2Decoder.decode
• BZh
• event loop blocked
• EventLoop blocked
• blocked event loop
• Netty event loop
• nioEventLoopGroup
• EpollEventLoop
• NioEventLoop
• KQueueEventLoop
• request timed out
• connection reset by peer

What your security team should do

• Inventory Java applications, gateways, SDKs, and services that include Netty and identify any versions earlier than 4.1.136.Final or 4.2.16.Final.
• Prioritize internet-facing, API gateway, proxy, file ingestion, messaging, and protocol services that accept compressed or user-controlled network input.
• Upgrade affected applications to Netty 4.1.136.Final, 4.2.16.Final, or newer and redeploy the running artifacts.
• Temporarily block or disable bzip2-compressed input from untrusted sources where business functionality allows.
• Add monitoring for Netty event-loop stalls, sustained single-process CPU saturation, request timeout spikes, and abnormal connection backlog growth.
• Review recent logs, metrics, and thread dumps for signs of event-loop threads stuck in Bzip2BlockDecompressor.read().
• Create SIEM or observability alerts for repeated bzip2 payloads, Bzip2Decoder errors, blocked event-loop warnings, and unexplained availability incidents on Netty-based services.