CVE-2026-42584: Netty Information Disclosure Vulnerability

CVE-2026-42584 Overview

CVE-2026-42584 is an HTTP request smuggling vulnerability in Netty, an asynchronous event-driven network application framework widely used in Java applications. The flaw resides in HttpClientCodec, which incorrectly pairs inbound responses with outbound requests when 1xx informational responses are involved. When a client pipelines a GET followed by a HEAD request, a server response sequence of 103, 200 with body, then 200 for HEAD causes the codec to associate HEAD with the first 200. The HEAD rule then skips the body read, leaving GET entity bytes on the wire and parsing the next response from the wrong offset. The issue is fixed in versions 4.2.13.Final and 4.1.133.Final.

Critical Impact

Response desynchronization in pipelined HTTP traffic allows attackers to corrupt response parsing, potentially exposing one user's response data to another or enabling cache poisoning.

Affected Products

• Netty versions prior to 4.2.13.Final (4.2.x branch)
• Netty versions prior to 4.1.133.Final (4.1.x branch)
• Applications using HttpClientCodec with HTTP pipelining enabled

Discovery Timeline

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

Technical Details for CVE-2026-42584

Vulnerability Analysis

The vulnerability is classified as [CWE-444] Inconsistent Interpretation of HTTP Requests, commonly known as HTTP request/response smuggling. Netty's HttpClientCodec maintains an internal queue that tracks outstanding outbound HTTP method requests. When responses arrive, the codec calls queue.poll() once per response to determine how to parse the body, including for 1xx informational responses such as 103 Early Hints.

This pairing logic is incorrect. 1xx responses are non-terminal and must not consume an entry from the request queue. The queue poll causes subsequent terminal responses to be paired with the wrong outbound request method.

Root Cause

The root cause lies in HttpClientCodec's response-to-request pairing logic. The codec treats every inbound response, including 1xx informational responses, as a terminal response for queue accounting purposes. Per RFC 9110, 1xx responses are interim and a single request can receive multiple 1xx responses before a final response.

When a client pipelines GET then HEAD and the server sends 103, then 200 with a GET body, then 200 for HEAD, the queue pairs the first terminal 200 with HEAD instead of GET. The HEAD-response rule then skips reading the message body, leaving the actual GET entity bytes unread on the stream.

Attack Vector

An attacker controlling a malicious or compromised server, or a man-in-the-middle on cleartext HTTP, can craft response sequences that desynchronize the parser. After desynchronization, body bytes intended for one response become the headers of the next parsed response. This enables response smuggling, where attacker-controlled content can be interpreted as headers or status lines of subsequent responses, potentially poisoning client-side caches or leaking response data across logical request boundaries.

The vulnerability requires HTTP pipelining and is triggered by 1xx interim responses such as 103 Early Hints mixed with HEAD requests in the pipeline.

No verified public proof-of-concept code is available. Refer to the GitHub Security Advisory GHSA-57rv-r2g8-2cj3 for technical details.

Detection Methods for CVE-2026-42584

Indicators of Compromise

• Unexpected response parsing errors or malformed header exceptions in Netty client logs after receiving 103 Early Hints responses.
• Mismatched Content-Length or chunked encoding errors logged by HttpObjectDecoder following pipelined requests.
• Application logs showing response body content appearing where headers are expected.

Detection Strategies

• Inventory Java applications and dependencies for vulnerable Netty versions using software composition analysis tools that scan pom.xml, build.gradle, and uber-JARs.
• Inspect network captures for HTTP 103 responses sent to clients that pipeline HEAD requests, which is the trigger pattern.
• Enable verbose logging on HttpClientCodec and review for unusual decode state transitions or pairing anomalies.

Monitoring Recommendations

• Monitor outbound HTTP client connections from Netty-based services for protocol errors and unexpected connection resets.
• Track exception stack traces originating from io.netty.handler.codec.http.HttpClientCodec and HttpObjectDecoder classes.
• Alert on dependency drift where Netty versions remain below 4.1.133.Final or 4.2.13.Final after the patch window.

How to Mitigate CVE-2026-42584

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or 4.1.133.Final depending on which branch is in use.
• Identify all transitive Netty dependencies in build artifacts, including shaded and relocated copies inside fat JARs.
• Restart all services that load Netty classes after upgrading to ensure the patched code is active.

Patch Information

The vulnerability is fixed in Netty 4.2.13.Final and 4.1.133.Final. The patch corrects HttpClientCodec so that 1xx informational responses no longer consume an entry from the request queue, restoring correct response-to-request pairing. See the GitHub Security Advisory GHSA-57rv-r2g8-2cj3 for the official patch details.

Workarounds

• Disable HTTP pipelining in Netty-based clients where feasible, since the vulnerability requires multiple in-flight requests on one connection.
• Avoid mixing HEAD requests with other methods on pipelined connections until the upgrade is applied.
• Restrict client traffic to trusted servers that do not emit 103 Early Hints responses, reducing exposure to the trigger condition.

# Maven dependency upgrade example
mvn versions:use-dep-version -Dincludes=io.netty:netty-codec-http -DdepVersion=4.1.133.Final -DforceVersion=true

# Gradle dependency override example
# In build.gradle:
# implementation('io.netty:netty-codec-http:4.1.133.Final')

# Verify resolved version
mvn dependency:tree | grep netty-codec-http