CVE-2026-42584: Netty: HttpClientCodec response desynchronization

Published May 7, 2026
·
Updated

### 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

4 affected componentsFixes available
maven/io.netty:netty-codec-http<=4.1.132.Final
4.1.133.Final
maven/io.netty:netty-codec-http>=4.2.0.Alpha1<=4.2.12.Final
4.2.13.Final
Netty Netty<4.1.133
Netty Netty>=4.2.0<4.2.13

Event History

May 7, 2026
Advisory Published
via GitHub·12:21 AM
Data Sourced
via GitHub·12:21 AM
DescriptionSeverityWeaknessAffected Software
May 13, 2026
CVE Published
via MITRE·06:10 PM
Data Sourced
via MITRE·06:10 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:17 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

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.

2

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.

3

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.

4

What causes the vulnerability in CVE-2026-42584?

The vulnerability in CVE-2026-42584 arises from HttpClientCodec wrongly associating inbound responses with outbound requests.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203