CVE-2026-59901: 
Java 취약성 분석 및 완화

CVE-2026-59901 is a denial-of-service vulnerability in Netty's Bzip2Decoder handler, titled "Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang." The flaw exists in the run-length encoding (RLE) state machine within Bzip2BlockDecompressor.read() in Netty's compression codec pipeline. Affected packages are io.netty:netty-codec (versions before 4.1.136.Final) and io.netty:netty-codec-compression (versions 4.2.0.Final through before 4.2.16.Final). The vulnerability was published by Netty maintainer normanmaurer on July 14, 2026, and added to the GitHub Advisory Database on July 22, 2026. It carries a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Netty Security Advisory).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). The vulnerability resides in the RLE state machine within Bzip2BlockDecompressor.read(), which can be driven into an infinite loop when processing a specially crafted, malformed bzip2 stream. Because Netty uses an event-loop threading model, a single thread permanently stuck in this loop renders the entire event loop unresponsive — no authentication or special privileges are required to trigger the condition, and the attack can be launched remotely over the network with low complexity (Github Advisory, Netty Security Advisory).

Successful exploitation causes the targeted Netty event-loop thread to hang permanently, making the service completely unresponsive to all subsequent requests. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Because Netty is widely used as a foundational networking framework in Java-based middleware, application servers, and microservices, the blast radius can extend to any application layer built on top of the affected Netty instance (Github Advisory).

1. Reconnaissance: Identify services running on Netty that accept bzip2-compressed data (e.g., HTTP endpoints with Content-Encoding: bzip2 or custom protocols using Netty's Bzip2Decoder in their pipeline). Tools like Shodan, Censys, or targeted HTTP probing can help identify candidates.
2. Craft malformed bzip2 stream: Construct a bzip2 payload that triggers the infinite loop in the RLE state machine within Bzip2BlockDecompressor.read(). The payload must be a syntactically plausible but semantically malformed bzip2 stream that causes the RLE decoder to enter an unreachable exit condition.
3. Deliver the payload: Send the malformed bzip2 stream to the target service over the network — for example, as the body of an HTTP request with Content-Encoding: bzip2, or via any protocol channel that routes data through the Bzip2Decoder handler in the Netty pipeline.
4. Trigger the hang: The Bzip2BlockDecompressor.read() method enters an infinite loop processing the malformed RLE data, permanently capturing the Netty event-loop thread.
5. Achieve denial of service: With the event-loop thread frozen, the service becomes unable to process any further requests, effectively taking it offline until the process is restarted (Github Advisory, Netty Security Advisory).

• Network: Unexpected or anomalous HTTP requests (or other protocol traffic) with Content-Encoding: bzip2 or bzip2-compressed payloads sent to Netty-based services; repeated connection attempts from the same source IP delivering compressed data.
• Process: Netty JVM process showing 100% CPU utilization on a single thread sustained over time; thread dumps revealing a Netty I/O thread permanently stuck in Bzip2BlockDecompressor.read() or related RLE state machine methods.
• Logs: Application logs showing the service stops responding to new requests after receiving a specific connection; absence of new request processing log entries following a particular inbound connection; JVM thread dump logs showing a blocked/spinning event-loop thread.
• Availability: Service health checks or monitoring alerts indicating the application is unresponsive despite the JVM process remaining alive.

Upgrade to the patched versions: io.netty:netty-codec 4.1.136.Final or io.netty:netty-codec-compression 4.2.16.Final (Netty 4.1.136 Release, Netty 4.2.16 Release). As a temporary workaround, disable bzip2 compression support in the Netty pipeline if it is not operationally required. Additionally, consider deploying a reverse proxy or WAF rule to reject or drop requests containing bzip2-encoded content before they reach the Netty application (Github Advisory).