Netty vulnerabilities

In the Netty library (netty-codec-redis) before versions 4.1.135.Final and 4.2.15.Final, a DoS vulnerability was found. An attacker can cause memory exhaustion and an OutOfMemoryError by sending a crafted Redis payload with deeply nested arrays, forcing the server to allocate a massive number of state objects and collections.

In Netty prior to versions 4.1.135.Final and 4.2.15.Final, IPv6 subnet rules can be bypassed due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions.

In netty incubator codec.bhttp prior to version 0.0.21.Final, HKDF_expand returns non-NULL on failure, leading to an all-zero key. Also, EVP_HPKE_CTX_export returns an empty zero-filled array on failure, resulting in a deterministic, predictable AEAD key.

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, the MQTT 5 header Properties section is parsed and buffered before any message size limit is applied. Specifically, in MqttDecoder, the decodeVariableHeader() method is called before the bytesRemainingBeforeVariableHeader > maxBytesInMessage check. The decodeVariableHeader() can call other methods which will call decodeProperties(). Effectively, Netty does not apply any limits to the size of the properties being decoded. Additionally, because MqttDecoder extends ReplayingDecoder, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion. This can cause high resource usage in both CPU and memory. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

A vulnerability in Netty (prior to 4.2.13.Final and 4.1.133.Final) in HttpContentDecompressor. The maxAllocation parameter limiting decompression buffer size is correctly enforced for gzip and deflate encodings but silently ignored for br (Brotli), zstd, and snappy. An attacker can bypass the decompression limit by sending a compressed payload with Content-Encoding: br instead of gzip, causing unbounded memory allocation and out-of-memory denial of service. The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.

A vulnerability in Netty's HttpClientCodec component causes incorrect pairing of HTTP responses with requests when using pipelining with GET and HEAD requests. When the server returns 103 and 200 responses, the queue pairs the HEAD response with the first 200 response, leading to incorrect data reading and stream offset.

In Netty before version 4.2.13.Final, the QpackDecoder's decodeHuffmanEncodedLiteral method allocates a byte array based on a length value from the wire without checking if enough readable bytes exist. An attacker can exploit this by sending crafted HTTP/3 header blocks, causing excessive memory allocation and denial of service.

A vulnerability in Netty before versions 4.2.13.Final and 4.1.133.Final in HttpObjectDecoder allows request smuggling for HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers. An attacker can send such a request, causing message boundary disagreement.

Netty, an asynchronous event-driven network application framework, has a vulnerability in its DNS codec that does not enforce RFC 1035 domain name constraints during encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder.

Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation disabled, allowing an attacker controlling outbound headers to inject arbitrary HTTP headers. The vulnerability affects versions prior to 4.2.13.Final and 4.1.133.Final.

A vulnerability in Netty before versions 4.1.132.Final and 4.2.10.Final allows a DoS attack by flooding CONTINUATION frames. The lack of a frame count limit and bypass of size mitigations via zero-byte frames cause excessive CPU consumption.

A vulnerability in Netty prior to versions 4.1.132.Final and 4.2.10.Final causes incorrect parsing of quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

The vulnerability in `SniHandler` in the Netty framework allows for the allocation of up to 16MB of heap for each channel during the TLS handshake. The lack of proper checks enables the crafting of a packet that can exploit this allocation, potentially leading to resource exhaustion.