Netty HTTP Codec Vulnerabilities

HTTP request smuggling in Netty's netty-codec-http (HttpObjectDecoder) lets remote attackers desynchronize message boundaries by sending an HTTP/1.0 request carrying both Transfer-Encoding: chunked and Content-Length. Netty's anti-smuggling sanitization that strips the conflicting Content-Length header only runs for HTTP/1.1, so on HTTP/1.0 Netty parses the body as chunked while leaving Content-Length intact for any downstream Content-Length-first proxy, which then treats trailing chunk bytes as a new request. Publicly available exploit code exists (a working EmbeddedChannel PoC test), but EPSS is very low (0.03%, 8th percentile) and it is not in CISA KEV.

HTTP response desynchronization in Netty's HttpClientCodec (netty-codec-http 4.1.x through 4.1.132.Final and 4.2.0.Alpha1 through 4.2.12.Final) lets a malicious or misbehaving server cause one request's response body to be parsed as another's. Because the codec polls its request queue once per inbound response — including for informational 1xx — a pipelined GET+HEAD sequence preceded by a 103 mispairs the HEAD with the GET's 200, leaving GET entity bytes on the wire so the following response is parsed from the wrong offset. Rated CVSS 9.1 (I:H/A:H), publicly available exploit code exists (a vendor PoC ships in the advisory), though EPSS is very low (0.04%) and it is not on CISA KEV.

Improper enforcement of RFC 1035 domain-name constraints in Netty's DNS codec (io.netty.handler.codec.dns.DnsCodecUtil) lets attacker-influenced names bypass validation in both directions: the decoder accepts oversized labels (>63 bytes) and total names (>255 bytes) from malicious DNS responses, growing an unbounded StringBuilder, while the encoder passes through null bytes and over-length labels and silently truncates on empty labels. This affects any Java application using netty-codec-dns or netty-resolver-dns (e.g. DnsNameResolver) up to 4.2.12.Final and 4.1.132.Final, enabling DNS cache poisoning, domain allowlist/validation bypass, and memory-exhaustion denial of service. Publicly available exploit code exists (vendor-supplied encoder and decoder PoCs verified on 4.2.12.Final), but EPSS is very low (0.04%, 13th percentile) and it is not in CISA KEV.

Decompression bomb protection bypass in Netty's HttpContentDecompressor and DelegatingDecompressorFrameListener allows remote unauthenticated attackers to trigger out-of-memory denial of service by switching Content-Encoding from gzip to brotli, zstd, or snappy. The configured maxAllocation parameter correctly limits gzip/deflate decompression but is silently ignored for these alternative encodings, enabling attackers to decompress gigabytes of data from kilobyte-sized payloads. Affects both HTTP/1.1 (netty-codec-http) and HTTP/2 (netty-codec-http2) implementations. CVSS 7.5 (High) with network vector, low complexity, and no authentication required. Vendor-released patches available: versions 4.1.133.Final and 4.2.13.Final. No active exploitation confirmed at time of analysis, but publicly disclosed proof-of-concept demonstrates trivial header-based bypass requiring only changing 'Content-Encoding: gzip' to 'Content-Encoding: br'.

Memory exhaustion in Netty's Lz4FrameDecoder allows remote unauthenticated attackers to cause denial of service by sending minimal malicious data that triggers disproportionate server-side memory allocation. A 22-byte crafted LZ4 frame forces the decoder to allocate up to 32MB of heap memory per request, enabling resource exhaustion attacks against Java applications using Netty's compression codec. Publicly available exploit code exists (PoC published in GitHub advisory GHSA-mj4r-2hfc-f8p6). CVSS 7.5 indicates network-exploitable high-availability impact with no authentication or complexity barriers, though real-world risk depends on whether LZ4 decompression is exposed to untrusted network inputs.

Memory exhaustion in Netty HTTP/3 codec allows remote attackers to cause server crash or denial of service through malformed QPACK headers. The vulnerability affects io.netty:netty-codec-http3 versions up to 4.2.12.Final and enables unauthenticated attackers to force gigabyte-scale memory allocations with minimal wire data-a crafted HEADERS frame of just 10 bytes can trigger ~1 GiB allocation. Publicly available exploit code exists (PoC provided in GitHub advisory GHSA-2c5c-chwr-9hqw). CVSS 7.5 (High) reflects network-accessible attack requiring no privileges or user interaction.

CRLF injection in Netty's RedisEncoder allows remote command injection and response poisoning by injecting carriage return and line feed characters into InlineCommandRedisMessage, SimpleStringRedisMessage, and ErrorRedisMessage objects. Attackers can inject arbitrary Redis commands (such as CONFIG SET, FLUSHALL, or authentication bypass) or forge fake responses when user-controlled input is placed into these message types without sanitization. The vulnerability affects Netty 4.2.12.Final and all prior versions with the codec-redis module; no active exploitation has been reported in CISA KEV, but publicly available proof-of-concept code demonstrates the vulnerability.

HTTP request smuggling in Netty's chunk size parser allows remote unauthenticated attackers to inject arbitrary HTTP requests by exploiting integer overflow in the hexadecimal chunk size parsing logic. The HttpObjectDecoder.getChunkSize method accumulates the chunk size without proper overflow validation, enabling an attacker to craft a malicious chunk size header that wraps around to a valid size, causing Netty to misinterpret the request boundary and parse injected requests as separate legitimate requests. Publicly available proof-of-concept demonstrates successful parsing of an injected GET request within a chunked POST body, with CVSS score 6.5 (network-accessible, low complexity, no authentication required).

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. The vulnerability is confirmed by public proof-of-concept code demonstrating successful parsing of injected requests.

HTTP header injection via CRLF sequences in Netty's HttpProxyHandler allows remote attackers to inject arbitrary HTTP headers into CONNECT proxy requests by supplying malicious outbound headers, bypassing the incomplete fix for GHSA-84h7-rjj3-6jx4. The vulnerability affects Netty 4.1.x up to 4.1.132.Final and 4.2.x up to 4.2.12.Final; unauthenticated remote exploitation is possible when applications pass user-influenced headers to HttpProxyHandler without performing their own CRLF sanitization. CVSS 7.5 (high integrity impact); no public exploit code confirmed at time of analysis, but proof-of-concept source code is provided in the advisory.