7.3

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-42584

CVE-2026-42584: Netty: HttpClientCodec response desynchronization

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpClientCodec pairs each inbound response with an outbound request by queue.poll() once per response, including for 1xx. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-42584

CVE-2026-42584:

7.3

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
io.netty:netty-codec-http	maven	>= 4.2.0.Alpha1, <= 4.2.12.Final	4.2.13.Final
io.netty:netty-codec-http	maven	<= 4.1.132.Final	4.1.133.Final

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, identified as GHSA-57rv-r2g8-2cj3, is a response desynchronization issue in Netty's HttpClientCodec. The root cause is the incorrect handling of HTTP/1.1 pipelined requests when a server sends a 1xx informational response. The analysis of the patch commit ada0999ae6a011c787203108c8d987e0bc25b82d reveals the exact location of the flaw. The vulnerable code is within the isContentAlwaysEmpty method of the private inner class Decoder in HttpClientCodec. Before the fix, this method would consume a pending request from its queue for every response received, including non-final 1xx informational responses. This behavior breaks the request-response pairing when pipelining is used. For example, if a client sends a GET followed by a HEAD, and the server sends a 103 Early Hints for the GET, the codec would consume the GET request from the queue. When the subsequent 200 OK for the GET arrives, the codec would then consume the HEAD request from the queue, mistakenly pairing the GET response body with the HEAD request. Since HEAD responses should not have a body, the codec would skip reading it, leaving the data on the stream and desynchronizing the connection. The patch corrects this by moving the queue.poll() operation to after the check for informational responses, ensuring that the request queue is only advanced for final responses (non-1xx). The identified vulnerable function, io.netty.handler.codec.http.HttpClientCodec$Decoder.isContentAlwaysEmpty, is the precise point where this flawed logic was executed.

Vulnerable functions

io.netty.handler.codec.http.HttpClientCodec$Decoder.isContentAlwaysEmpty

codec-http/src/main/java/io/netty/handler/codec/http/HttpClientCodec.java

The vulnerability lies in the `isContentAlwaysEmpty` method of the inner `Decoder` class. The original code polled a request from the queue (`queue.poll()`) before checking if the incoming HTTP response was an informational one (e.g., 1xx status code). Informational responses are not final and are followed by another response for the same request. By polling the queue for these non-final responses, the codec would incorrectly associate the next final response with the subsequent request in the pipeline. This desynchronization could lead to a response intended for one request being processed as the response for a different request, causing response smuggling.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.