Skip to main content

Netty HTTP Codec CVE-2026-42584

HIGH
HTTP Request/Response Smuggling (CWE-444)
2026-05-07 https://github.com/netty/netty GHSA-57rv-r2g8-2cj3
7.3
CVSS 3.1
Share

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Lifecycle Timeline

3
Source Code Evidence Fetched
May 07, 2026 - 00:46 vuln.today
Analysis Generated
May 07, 2026 - 00:46 vuln.today
CVE Published
May 07, 2026 - 00:21 nvd
HIGH 7.3

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 11 maven packages depend on io.netty:netty-codec-http (11 direct, 0 indirect)

Ecosystem-wide dependent count for version 4.2.0.Alpha1.

DescriptionNVD

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.

AnalysisAI

HTTP response desynchronization in Netty's HttpClientCodec allows response body misattribution across pipelined requests when servers send 1xx informational responses. When a client pipelines GET and HEAD requests and the server responds with 103 Early Hints followed by 200 responses, the codec incorrectly pairs the HEAD request with the GET's 200 response, causing the GET response body to remain on the stream and corrupt subsequent response parsing. …

Sign in for full analysis, threat intelligence, and remediation guidance.

RemediationAI

Within 24 hours: inventory all applications and dependencies using Netty versions before 4.1.133.Final or 4.2.13.Final; identify systems processing pipelined HTTP requests. Within 7 days: deploy Netty 4.1.133.Final or 4.2.13.Final across all affected applications; prioritize systems exposed to untrusted networks. …

Sign in for detailed remediation steps.

Vendor StatusVendor

Share

CVE-2026-42584 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy