Netty vulnerabilities

Netty, an asynchronous network application framework, has an issue in versions from 4.2.0.Final to 4.2.13.Final where the epoll transport fails to detect and close TCP connections that receive a RST after being half-closed. This leads to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.

In Netty versions 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final, a vulnerability in OpenSslEngine.java allows remote attackers to cause a denial of service (infinite loop).

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.

Netty versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final have a vulnerability in XmlDecoder where delivering XML with a DOCTYPE declaration to an AsyncXMLInputFactory without security configuration can activate DTD and entity handling, creating XML External Entity (XXE) risk.

Netty (io.netty:netty-codec-http2) before version 4.1.61.Final contains a vulnerability enabling request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with endStream set to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which missed to fix this one case. Fixed as part of 4.1.61.Final.

Netty (io.netty:netty-codec-http2) before version 4.1.60.Final contains a vulnerability enabling request smuggling. When an HTTP/2 request is converted to HTTP/1.1 by `Http2StreamFrameToHttpObjectCodec` and forwarded to a remote peer, the Content-Length header is not validated by `Http2MultiplexHandler`, allowing an attacker to smuggle additional requests within the body.

HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header, which may lead to improper processing of HTTP requests.

HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with incorrect syntax or as an "invalid fold". This can lead to incorrect parsing of HTTP requests.

Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP request smuggling.

Netty HttpServerCodec up to 4.2.17.Final and 4.1.137.Final incorrectly pairs responses with requests when HTTP/1.1 pipelining with Expect: 100-continue is used, leading to response splitting and unsafe connection reuse.

Netty from 4.2.11.Final before 4.2.18.Final has an incomplete hostname verification fix in the QUIC certificate path when using a plain X509TrustManager, allowing attackers to present a certificate for the wrong hostname.

Netty's HTTP/3 codec from 4.2.2.Final through 4.2.17.Final builds the :authority pseudo-header from the Host header before considering the authority of an absolute-form request-target, leading to authority confusion.

Netty's HTTP/3 codec from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets, resulting in malformed HTTP/3 CONNECT with attacker-controlled authority.

Netty's HTTP/3 codec from 4.2.0.Final through 4.2.17.Final has an uncontrolled resource consumption vulnerability in the QPACK encoder-stream instruction decoder, allowing an attacker to declare huge literal lengths, causing unbounded heap growth and OutOfMemoryError.

Netty's QPACK prefixed-integer decoder (netty-codec-http3) from 4.2.0.Final through 4.2.17.Final does not bound continuation bytes, allowing an attacker to cause O(N^2) CPU cost and memory growth, leading to OOM and event-loop starvation.

Netty's HTTP/3 codec from 4.2.0.Final through 4.2.17.Final retains unbounded per-stream QPACK encoder state, allowing an attacker to cause unbounded heap growth and denial of service.

Netty's HTTP/3 codec (io.netty:netty-codec-http3) in versions 4.2.0.Final through 4.2.17.Final does not enforce the RFC 9114 requirement that the :authority pseudo-header field and a literal host header field, when both present, carry the same value. A remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values; the request is accepted and delivered to the application with two conflicting authorities, allowing routing, virtual-host, and access-control decisions to be bypassed when different components in the request path consult different fields. This issue is fixed in 4.2.18.Final.

A flaw in Netty's `netty-codec-http` component. A remote attacker can send a specially crafted HTTP/1.1 chunk-size token that includes post-digit whitespace. This incorrect parsing of the chunk size can lead to HTTP request smuggling.

A flaw 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.

A flaw was found in Netty's HTTP/2 stack that allows a remote attacker to inject prohibited characters, such as NUL, Line Feed, and Carriage Return, into HTTP/2 header field values due to insufficient validation. When these values cross an HTTP/2 to HTTP/1.1 translation boundary, they can be exploited for request smuggling, header injection, or response splitting.

A flaw in Netty netty-codec-smtp is the improper validation of Carriage Return (CR) and Line Feed (LF) characters in the SMTP command-name field. A remote attacker, if an application routes untrusted input into this field, can embed CR/LF characters to inject arbitrary SMTP commands, leading to SMTP command smuggling.

A flaw in Netty's HTTP/1.1 decoder allows a remote attacker to bypass Transfer-Encoding header validation by splitting the field across multiple headers, with the last containing a non-final transfer coding like gzip or deflate. This bypass can lead to HTTP request smuggling.

A flaw in Netty's HTTP/1 to HTTP/2 conversion process occurs when an HTTP/1 request includes both an absolute-form request-target and a conflicting Host header. Netty incorrectly prioritizes the Host header for the HTTP/2 :authority field, discarding the original request-target authority.

A flaw in Netty causes specially crafted HTTP/2 or HTTP/3 Extended CONNECT requests to be incorrectly processed as regular HTTP/1.1 CONNECT requests, leading to a loss of critical protocol and path information.

A flaw in Netty's HTTP/2 codec. When converting HTTP/1 CONNECT requests to HTTP/2, the component incorrectly uses the Host header instead of the CONNECT authority-form request-target for the tunnel authority. A remote attacker can supply a different Host header, producing a malformed HTTP/2 CONNECT request.

A flaw in Netty allows a remote attacker to send a specially crafted HTTP request with control characters in the chunk-size line. This bypasses strict validation, allowing injection of arbitrary HTTP requests and request smuggling.

A flaw in Netty's RtspDecoder. The `RtspMethods.valueOf()` function incorrectly strips trailing control bytes from method tokens in RTSP requests. A remote attacker can send a specially crafted RTSP request, leading to method-token smuggling.

A flaw in Netty. A reference-count leak in the HAProxy PROXY-v2 message decoder allows a remote, unauthenticated attacker to send specially crafted PROXY-protocol v2 headers. This leads to memory exhaustion.

A flaw in Netty's WebSocketServerExtensionHandler. A remote, unauthenticated attacker can use HTTP/1.1 pipelining to send requests faster than the application can respond. This leads to unbounded growth of a per-connection queue and excessive memory consumption.

A flaw in the Netty STOMP codec. A remote attacker can send a specially crafted STOMP frame with a content-length header exceeding the maximum integer value. This integer truncation vulnerability can lead to an infinite decode loop.

A flaw in Netty's HTTP/2 HpackEncoder allows a remote attacker to cause a Denial of Service by sending HTTP/2 SETTINGS frames with an excessively large MAX_HEADER_TABLE_SIZE. This leads to excessive storage of headers, increasing CPU and memory usage.

A flaw in Netty's HttpServerCodec allows a remote, unauthenticated attacker to pipeline HTTP/1.1 requests and withhold reads, causing the methodOverflowQueue to grow without limit, leading to unbounded heap memory consumption and denial of service.

In Netty, SpdySessionHandler accepts an unlimited number of concurrent remote-initiated streams because localConcurrentStreams defaults to Integer.MAX_VALUE and the handler provides no API to change it. A remote peer can open a SPDY connection and send a large number of SYN_STREAM frames with FLAG_FIN=0, causing unbounded heap and direct memory allocation that can lead to JVM OutOfMemoryError and denial of service.

A vulnerability in Netty's OCSP client fails to verify the 'id-kp-OCSPSigning' Extended Key Usage in OCSP responder certificates. A remote attacker holding any valid certificate from the same CA can forge 'GOOD' OCSP responses for revoked certificates, bypassing revocation checks.

A flaw in Netty's MqttDecoder. An unauthenticated remote attacker can send a specially crafted MQTT CONNECT packet. The decoder fails to properly validate the 'Properties Length' against the 'Remaining Length', allowing bypass of size limits.

A flaw in Netty's `RedisArrayAggregator` component. A remote attacker can send specially crafted nested Redis (RESP) array headers. This causes `RedisArrayAggregator` to eagerly preallocate a large amount of heap memory.

A flaw in Netty's `SmtpResponseDecoder` component. A remote attacker acting as a malicious or man-in-the-middle (MITM) SMTP server can send a specially crafted, unbounded multi-line SMTP response without a terminator. This leads to unbounded memory accumulation within the client's JVM heap.

A flaw was found in Netty's StompSubframeDecoder component. A remote attacker can exploit this vulnerability by sending a specially crafted STOMP frame body without its terminating null byte. This causes the decoder to allocate a ByteBuf (a buffer for bytes) that is never released, leading to a permanent memory leak. Over time, this uncontrolled memory consumption can result in a Denial of Service (DoS) for the application using the affected STOMP codec.

A flaw was found in Netty's netty-handler-ssl-ocsp component. A remote attacker can provide an OCSP response that omits the optional nextUpdate field, causing OCSP validation to be silently skipped and applications to proceed with an unvalidated certificate.

Netty versions 4.1.133.Final through 4.1.137.Final and 4.2.13.Final through 4.2.17.Final fail to properly validate the final transfer coding in the Transfer-Encoding header. Attackers can split the header across multiple lines or use values like 'chunked, xchunked' to bypass validation and decode messages incorrectly.

Netty prior to versions 4.1.137.Final and 4.2.17.Final has a vulnerability in MqttEncoder that does not validate client identifiers, will topics, usernames, and PUBLISH topic names before encoding, allowing prohibited null bytes in MQTT UTF-8 string fields. This can cause routing, access-control, or identity mismatches in downstream brokers.

Netty (io.netty:netty-codec-socks) versions 4.2.0.Final through 4.2.16.Final and 4.1.x through 4.1.136.Final contain null byte, CRLF, and credential injection vulnerabilities in the SOCKS4 (Socks4ClientEncoder) and SOCKS5 (Socks5ClientEncoder) client encoders, which fail to validate domain address and authentication (username/password) fields. An attacker able to control these fields can inject null bytes or CRLF characters to truncate or alter values, potentially enabling domain spoofing, SOCKS4 userid truncation, authentication data injection, and protocol confusion. Fixed in 4.2.17.Final and 4.1.137.Final.

Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is used and Unsafe-based trust-manager wrapping is unavailable (Java 25+). In this configuration the OpenSSL client does not perform hostname verification, allowing a man-in-the-middle attacker to present a certificate issued for a different hostname that is accepted without validation. Fixed in 4.2.17.Final and 4.1.137.Final.

In Netty prior to 4.1.137.Final and 4.2.17.Final, the default SniHandler constructors use the pre-handshake ClientHello aggregation path, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients.

Netty before 4.1.137.Final and 4.2.17.Final has a vulnerability in CorsHandler setVaryHeader that replaces application Vary headers such as Authorization or Cookie with Origin, allowing a caching proxy or CDN to reuse authenticated responses across users and disclose sensitive information.

Netty before versions 4.1.137.Final and 4.2.17.Final limits incomplete messages and fragment counts but not maxBufferedBytes, allowing unauthenticated peers to exhaust memory with large SCTP fragments. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.

Netty before versions 4.1.136.Final and 4.2.16.Final failed to release retained or newly allocated ByteBuf objects when IDN.toASCII() or encodeDomainName() rejected a malformed domain name. Remote DNS packets can leak direct memory incrementally until denial of service.

Netty before versions 4.1.136.Final and 4.2.16.Final has a vulnerability in XmlFrameDecoder.decode() that fails to preserve closing-tag parser state across invocations. An unauthenticated remote attacker can trickle-feed repeated </ sequences, causing repeated rescans of the accumulated buffer and exhausting an EventLoop thread's CPU, leading to denial of service with a maxFrameLength of 1 MB.

In Netty before versions 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator codec does not clear partial aggregate state after exceeding the maxElements limit, allowing an unauthenticated peer to keep aggregate state alive after an exception and pin retained pooled buffers.

Netty prior to versions 4.1.136.Final and 4.2.16.Final is vulnerable to a forced WebSocket upgrade via the lax V07/V08 handshaker. An attacker can send Sec-WebSocket-Version: 7 while omitting Connection: Upgrade and Upgrade: websocket headers, completing a protocol switch unrecognized by proxies, enabling HTTP request smuggling and protocol-confusion attacks.