A flaw was found in Netty's HTTP/1.1 decoder. This vulnerability allows a remote attacker to bypass Transfer-Encoding header validation by splitting the Transfer-Encoding field across multiple headers, with the last field containing a non-final transfer coding like gzip or deflate. This bypass can lead to HTTP request smuggling, enabling attackers to bypass security controls, desynchronize request processing, or cause requests to be processed in an unintended context.
A flaw was found in Netty. A remote attacker could exploit this by sending a specially crafted HTTP request that includes control characters within the chunk-size line. This bypasses the intended strict validation, allowing the attacker to inject arbitrary HTTP requests. This vulnerability can lead to HTTP request smuggling, potentially resulting in information disclosure or other unauthorized actions.
A flaw was found in Netty's HTTP/1 decoder. Incomplete validation of malformed Transfer-Encoding headers allows a remote attacker to perform HTTP request smuggling. By sending specially crafted HTTP requests, an attacker can inject arbitrary HTTP requests, potentially bypassing security controls or accessing unauthorized resources.
A flaw was found in Netty's HttpServerCodec. A remote, unauthenticated attacker can exploit this vulnerability by pipelining HTTP/1.1 requests on a single connection and withholding reads. This action causes the methodOverflowQueue to grow without limit, leading to unbounded heap memory consumption and a denial of service due to memory exhaustion.
A flaw was found in Netty RtspDecoder. The RtspMethods.valueOf() function incorrectly strips trailing control bytes from method tokens in Real-Time Streaming Protocol (RTSP) requests. A remote attacker can exploit this by sending a specially crafted RTSP request, leading to method-token smuggling. This vulnerability allows an attacker to bypass method-based access controls and can also be used to launder malicious requests through Netty-based RTSP proxies, making them appear legitimate to backend systems.
Netty is an asynchronous event-driven network application framework widely used for HTTP and other protocols.
A public GitHub Security Advisory (GHSA-pvjx-v7vp-62vq) reports that HttpServerCodec tracks, per connection, which HTTP method each still-unanswered pipelined request used. The first 32 pending entries are bit-packed into a single long, but every entry beyond that spills into methodOverflowQueue, an ArrayDeque with no upper bound.
A remote, unauthenticated attacker who pipelines HTTP/1.1 requests on one connection while withholding reads can grow this queue without limit, causing unbounded heap growth and a memory-exhaustion denial of service. This is the same defect class previously fixed in the sibling class HttpContentEncoder (CVE-2026-59899); HttpServerCodec did not receive the equivalent pipeline-depth bound.
Affected package: io.netty:netty-codec-http Affected versions: <= 4.1.137.Final and >= 4.2.0.Final, <= 4.2.17.Final Fixed versions: 4.1.138.Final and 4.2.18.Final
Advisory: https://github.com/netty/netty/security/advisories/GHSA-pvjx-v7vp-62vq
Netty is a network application framework for development of protocol servers and clients.
SpdySessionHandler accepts an unlimited number of concurrent remote-initiated streams because localConcurrentStreams defaults to Integer.MAXVALUE and the handler provides no API to change it. When a remote peer opens a SPDY connection and sends millions of SYNSTREAM frames with FLAGFIN=0, the server allocates unbounded heap and direct memory, eventually triggering JVM OutOfMemoryError and crashing the service.
This issue is tracked by GitHub Security Advisory GHSA-rmcw-9fcq-wjq7. No CVE ID has been assigned yet.
Affected package: io.netty:netty-codec-http - <= 4.1.137.Final, fixed in 4.1.138.Final - >= 4.2.0.Final, <= 4.2.17.Final, fixed in 4.2.18.Final
Upstream advisory: https://github.com/netty/netty/security/advisories/GHSA-rmcw-9fcq-wjq7 Releases: https://github.com/netty/netty/releases/tag/netty-4.1.138.Final https://github.com/netty/netty/releases/tag/netty-4.2.18.Final
HTTP Request Smuggling due to control characters in the chunk-size line
A public GitHub Security Advisory (GHSA-rq4j-fc47-9698) describes the following issue:
Summary Netty skips strict chunk size line validation when the line has no chunk extension (;), so a chunk size line containing an embedded bare CR (e.g. 0\rX) is accepted instead of rejected, enabling HTTP request smuggling.
Details io.netty.handler.codec.http.HttpObjectDecoder#checkChunkExtensions only runs the strict validator HttpChunkLineValidatingByteProcessor when a ; is present:
java int extensionsStart = line.bytesBefore((byte) ';'); if (extensionsStart == -1) { return; }
According to RFC 9112 https://datatracker.ietf.org/doc/html/rfc9112#appendix-A
chunk-size = 1HEXDIG
PoC
java @Test public void test() { String requestStr = "POST / HTTP/1.1\r\n" + "Host: localhost\r\n" + "Transfer-Encoding: chunked\r\n\r\n" + "0\rX\r\n" + "\r\n" + "GET /smuggled HTTP/1.1\r\n" + "Host: localhost\r\n" + "Content-Length: 0\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()); LastHttpContent last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release();
// Request 2 (smuggled) request = channel.readInbound(); assertTrue(request.decoderResult().isSuccess()); assertEquals("/smuggled", request.uri()); last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release(); }
Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
Affected: - maven:io.netty:netty-codec-http affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-http affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-rq4j-fc47-9698
Incomplete validation of malformed Transfer-Encoding allows HTTP request smuggling
A public GitHub Security Advisory (GHSA-hcvj-94mj-jp5c) describes the following issue:
Summary
Netty's HTTP/1 decoder still accepts some malformed Transfer-Encoding values where chunked is present but is not the final transfer coding. This appears to be an incomplete fix / bypass of CVE-2026-42585 / GHSA-38f8-5428-x5cv. The canonical case Transfer-Encoding: chunked, gzip is rejected, but multi-line and pseudo-suffix variants are still accepted and decoded as chunked, which can lead to HTTP request smuggling in parser-differential deployments.
Details
The issue is in io.netty.handler.codec.http.HttpObjectDecoder#readHeaders.
Current behavior uses two different checks:
- HttpUtil.isTransferEncodingChunked(...) detects an exact chunked token anywhere in any Transfer-Encoding field. - readHeaders(...) then checks whether chunked is last by testing whether the last raw Transfer-Encoding field value ends with the string chunked.
This suffix check is not equivalent to parsing the final transfer-coding token.
Examples that are incorrectly accepted:
Transfer-Encoding: chunked Transfer-Encoding: gzip This is semantically equivalent to Transfer-Encoding: chunked, gzip, where chunked is not final.
Transfer-Encoding: chunked, xchunked
The final transfer coding is xchunked, not chunked, but the raw value ends with chunked.
RFC 9112 requires request messages where chunked is not the final transfer coding to be rejected with 400 and the connection closed.
PoC you can run this code TransferEncodingSmugglingReproducer.java
Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
This can be used as the fix patch netty-te-final-token.patch
Affected: - maven:io.netty:netty-codec-http affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-http affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-hcvj-94mj-jp5c
Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final, the HTTP decoder in netty-codec-http fails to properly limit decompression of HTTP body content encoded with gzip or other compression algorithms. An attacker can send HTTP requests with highly compressed payloads that decompress to enormous sizes, causing memory exhaustion and denial of service. This issue is fixed in versions 4.1.136.Final and later.