CVE-2026-59901: Netty Bzip2Decoder DoS Vulnerability

CVE-2026-59901 Overview

CVE-2026-59901 is a denial-of-service vulnerability in Netty, an asynchronous event-driven network application framework. The flaw resides in the Bzip2Decoder handler within Netty's compression codec pipeline. A malformed bzip2 stream triggers an infinite loop in the run-length encoding (RLE) state machine inside Bzip2BlockDecompressor.read(). This condition permanently captures the event-loop thread. Since Netty's event-loop threads process many concurrent connections, one malicious stream can degrade or halt service for all clients bound to the affected loop. The issue affects versions prior to 4.1.136.Final and 4.2.16.Final and is classified under CWE-835 (Loop with Unreachable Exit Condition).

Critical Impact
An unauthenticated remote attacker can send a crafted bzip2 payload to permanently trap a Netty event-loop thread, causing denial of service across all connections sharing that thread.

Affected Products

Netty versions prior to 4.1.136.Final
Netty versions prior to 4.2.16.Final
Applications using the Bzip2Decoder handler in Netty's compression codec pipeline

Discovery Timeline

2026-07-29 - CVE-2026-59901 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-59901

Vulnerability Analysis

The vulnerability sits in Netty's bzip2 decompression pipeline. Netty exposes Bzip2Decoder as a ChannelHandler that inbound data traverses on the event-loop thread. When the decoder encounters a malformed bzip2 stream, control reaches the run-length encoding state machine inside Bzip2BlockDecompressor.read(). The state machine fails to advance past a specific malformed input pattern and does not raise an exit condition. As a result, the calling thread spins indefinitely.

Because Netty multiplexes many channels onto a small pool of event-loop threads, trapping a single thread removes a significant fraction of the application's I/O capacity. A handful of malicious streams can stall the entire server. Fixed versions 4.1.136.Final and 4.2.16.Final add exit conditions to the RLE state machine.

Root Cause

The root cause is a missing termination guard in the RLE decoding loop within Bzip2BlockDecompressor.read(). Specific malformed byte sequences leave loop counters or state transitions in a configuration the code never detects as invalid. The decoder therefore never throws, returns, or advances the stream. CWE-835 describes exactly this defect class: a loop with an unreachable exit condition.

Attack Vector

Exploitation requires no authentication and no user interaction. Any network endpoint that accepts bzip2-compressed input and routes it through Netty's Bzip2Decoder is reachable. The attacker sends a single crafted bzip2 stream. The event-loop thread handling that connection enters the infinite loop and stops processing all other channels assigned to it. Repeating the payload against multiple connections exhausts the entire event-loop pool.

See the Netty GitHub Security Advisory GHSA-558v-64gr-wgg4 for the authoritative technical description.

Detection Methods for CVE-2026-59901

Indicators of Compromise

Netty event-loop threads (typically named nio-eventloop-* or epoll-eventloop-*) pinned at 100% CPU without progressing work
Sudden collapse in request throughput while connection counts remain stable
Thread dumps showing threads stuck inside io.netty.handler.codec.compression.Bzip2BlockDecompressor.read

Detection Strategies

Enumerate application dependencies for Netty versions below 4.1.136.Final and 4.2.16.Final using software composition analysis tooling
Alert on Java thread CPU saturation combined with stalled channel read counters exported by Netty metrics
Inspect ingress traffic for bzip2 magic bytes (0x425A68) directed at endpoints that do not require bzip2 input

Monitoring Recommendations

Capture periodic JVM thread dumps and flag frames referencing Bzip2BlockDecompressor or Bzip2Decoder
Track per-event-loop task queue depth and pending write bytes to catch stalled loops early
Log and rate-limit inbound requests carrying Content-Encoding: bzip2 or bzip2-framed payloads

How to Mitigate CVE-2026-59901

Immediate Actions Required

Upgrade Netty to 4.1.136.Final or 4.2.16.Final in all affected applications and rebuild dependent artifacts
Audit ChannelPipeline configurations for Bzip2Decoder usage and remove the handler where bzip2 support is not required
Enforce strict size limits on compressed payloads at upstream proxies or load balancers to reduce exposure until patching completes

Patch Information

The Netty maintainers released fixed builds in versions 4.1.136.Final and 4.2.16.Final. Both releases add proper exit conditions to the RLE state machine in Bzip2BlockDecompressor.read(). Full details are available in the Netty GitHub Security Advisory GHSA-558v-64gr-wgg4.

Workarounds

Remove Bzip2Decoder from the channel pipeline if bzip2 decompression is not a required feature
Reject requests with Content-Encoding: bzip2 at an upstream reverse proxy such as NGINX or Envoy
Isolate bzip2-handling endpoints on a dedicated event-loop group so a stalled loop does not affect unrelated traffic

bash

# Maven dependency override to enforce the patched Netty release
mvn versions:use-dep-version \
  -Dincludes=io.netty:netty-all \
  -DdepVersion=4.1.136.Final \
  -DforceVersion=true

# Gradle equivalent (build.gradle)
# configurations.all {
#     resolutionStrategy.eachDependency { details ->
#         if (details.requested.group == 'io.netty') {
#             details.useVersion '4.1.136.Final'
#         }
#     }
# }