Netty vulnerabilities

Netty prior to versions 4.2.13.Final and 4.1.133.Final has a vulnerability in Lz4FrameDecoder that allocates a ByteBuf of size decompressedLength, potentially leading to uncontrolled memory allocation. An attacker can exploit a 21-byte header and compressed data to force this allocation.

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

Netty prior to versions 4.1.136.Final and 4.2.16.Final does not escape or validate header values in STOMP CONNECT and CONNECTED frames, allowing an attacker to inject additional STOMP headers by controlling a header value (e.g., login or passcode). This can lead to authentication bypass or privilege escalation depending on the broker.

Netty prior to versions 4.1.136.Final and 4.2.16.Final does not validate AF_UNIX addresses for CRLF characters in the HAProxyMessageEncoder, allowing an attacker to inject \r\n sequences and split the PROXY header into multiple lines. This enables spoofing of client source/destination IP to a downstream server or load balancer.

In Netty prior to versions 4.1.136.Final and 4.2.16.Final, the `Bzip2Decoder` handler in the compression codec pipeline is vulnerable to a denial-of-service attack via a malformed bzip2 stream that causes an infinite loop in the event-loop thread. The vulnerability exists in the RLE state machine within `Bzip2BlockDecompressor.read()`.

Netty prior to versions 4.1.136.Final and 4.2.16.Final fails to deduplicate or validate Host headers during HTTP/2-to-HTTP/1.x translation. When an HTTP/2 client supplies both the :authority pseudo-header and a literal host header, the translator creates an HttpRequest with two different Host headers, enabling request smuggling or cache poisoning attacks.

Netty prior to versions 4.1.136.Final and 4.2.16.Final has a resource exhaustion vulnerability in HttpContentEncoder (superclass of HttpContentCompressor). The acceptEncodingQueue accumulates attacker-controlled data without size limit, and using HTTP/1.1 pipelining can lead to memory or I/O resource exhaustion.

Netty before versions 4.1.136.Final and 4.2.16.Final has a vulnerability in `OcspServerCertificateValidator` that forwards the `SslHandshakeCompletionEvent` before asynchronous OCSP validation completes. This allows the client to send sensitive data to a revoked server before the channel is closed.

Netty before versions 4.1.136.Final and 4.2.16.Final has a vulnerability in `OcspServerCertificateValidator` that marks an outdated OCSP response as valid even if expired. This allows an attacker to replay a stale GOOD response to bypass certificate revocation.

In Netty before versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating CRLF characters (\r\n). An attacker controlling the filename can inject arbitrary MIME headers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty versions 4.2.0.Final through 4.2.15.Final and prior to 4.1.135.Final do not validate that the CertificateID in an OCSP response matches the requested CertificateID. This enables a replay attack, allowing bypass of certificate revocation checks.

Netty versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final have a vulnerability where a remote unauthenticated peer can leak one direct ByteBuf per HTTP/2 DATA frame in applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener. When a DATA frame is processed for a stream whose decompressor has already been closed, Http2Decompressor.decompress(...) calls decompressor.writeInbound(data.retain()) and does not release the retained buffer on the error path, eventually exhausting direct memory and crashing the JVM.

In Netty prior to 4.2.16.Final, Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types without limits, trusting the payLoadLength field, allowing an attacker to open multiple QUIC streams and send frames with large payloads, causing memory exhaustion and denial of service.

Netty versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final are vulnerable to security control bypass during the origin evaluation process. CorsHandler provides a shortCircuit() configuration designed to reject unauthorized cross-origin requests immediately, but due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an Origin: null header. This forwards unauthorized requests to the backend application, bypassing intended access controls. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

In Netty up to versions 4.1.135 and 4.2.15, a vulnerability exists in the SpdyHttpDecoder handler. Improper release of a pooled ByteBuf leads to native memory exhaustion.

Netty, a network application framework, contains a vulnerability in the codec-haproxy module in the HAProxyMessageDecoder class. When reading the 13th byte as a signed byte and widening it to int without masking, the value 0xFF is interpreted as -1, causing a collision with the need-more-data sentinel. This leads to unbounded accumulation of data in the cumulation buffer until direct memory is exhausted.

Netty prior to versions 4.1.136.Final and 4.2.16.Final continues inflating zlib-compressed header blocks after maxHeaderSize is exceeded, allowing a remote peer to send a small compressed HEADERS block that expands into much larger raw header data, causing compression-amplified CPU and allocation churn.

Netty prior to versions 4.1.136.Final and 4.2.16.Final accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in DefaultSpdySettingsFrame, allowing a remote SPDY/3.1 peer to send a syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work.

Netty before versions 4.1.136.Final and 4.2.16.Final has a vulnerability in STOMP frame decoding where StompSubframeDecoder does not limit the total number of headers or their cumulative size. An attacker can send many short headers, causing JVM memory exhaustion and denial of service.

Netty, a network application framework, prior to versions 4.1.135.Final and 4.2.15.Final had an issue with handling max HTTP/2 header size, allowing an attack similar to HTTP/2 Rapid Reset. This could result in exceptions when writing response headers during request processing.

In versions prior to 4.1.135.Final and 4.2.15.Final, `HttpObjectDecoder` in the Netty framework skipped control bytes and whitespace before reading the first request line. This can lead to request-boundary confusion in complex transports, creating a risk of attacks.

A vulnerability in Netty RedisArrayAggregator pre-allocates an ArrayList with a capacity equal to the RESP array element count declared in a header, which can be inflated by a malicious packet. An attacker can send a small header with a fake large element count, leading to excessive memory consumption.

Netty prior to versions 4.1.135.Final and 4.2.15.Final has a vulnerability in SimpleTrustManagerFactory that bypasses hostname verification. A client configured with SslContextBuilder.forClient().trustManager() does not validate the certificate against the hostname, even when endpointIdentificationAlgorithm="HTTPS" is set.

Netty is a network application framework. Versions from 4.2.0.Final to 4.2.15.Final contain a memory exhaustion vulnerability in the HTTP/3 codec, allowing an infinite number of blocked streams, which can cause OOM. The issue is fixed in 4.2.15.Final.

A vulnerability in Netty causes native or heap memory leak on every connection when a client sends a syntactically valid HAProxy PROXY protocol v2 header containing nested PP2_TYPE_SSL TLVs at depth two or greater. The leak occurs on the successful parse path without throwing an exception, and releasing the HAProxyMessage does not free the underlying cumulation buffer.

In Netty before versions 4.1.135.Final and 4.2.15.Final, in the DelegatingDecompressorFrameListener class, a remote attacker can send HTTP/2 frames causing a resource leak, potentially leading to memory exhaustion and JVM crash.

A vulnerability in the Netty library causes permanent leakage of pooled direct-memory buffers in the RedisArrayAggregator handler when a Redis pipeline connection closes before RESP array aggregation completes. The handler retains child messages without releasing them on channel inactivation, leading to exhaustion of the direct-memory pool. The issue is fixed in versions 4.1.135.Final and 4.2.15.Final.

A vulnerability in Netty's `DnsResolveContext` allows DNS Cache Poisoning due to insufficient validation of NS record bailiwick. An attacker controlling an authoritative DNS server for a subdomain can inject fake A records for parent domains into the cache, redirecting traffic.

Netty, a network application framework, prior to versions 4.1.135.Final and 4.2.15.Final, does not limit the number of active streams in HTTP/2, potentially leading to excessive resource consumption. The lack of a default limit on the maximum number of streams can result in the creation of hundreds of thousands of stream objects in a single TCP connection.

In Netty library netty-transport-sctp prior to versions 4.1.135.Final and 4.2.15.Final, there is a resource exhaustion vulnerability. For each incomplete SctpMessage fragment, the handler creates a new CompositeByteBuf, leading to recursive buffer nesting. An attacker can send small fragments without the 'complete' flag, causing unlimited growth of the data structure and potential memory exhaustion.

A vulnerability in the Netty library involves missing validation of the origin (bailiwick) of CNAME records in DNS responses. The DnsResolveContext does not verify whether the CNAME record originates from an authoritative source, potentially leading to DNS cache poisoning attacks.

Netty, a network application framework, prior to versions 4.1.135.Final and 4.2.15.Final, used a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning.

In versions prior to 4.1.135.Final and 4.2.15.Final of the Netty framework, there is a vulnerability related to improper handling of SCM_RIGHTS messages, leading to file descriptor leaks. Due to incorrect message length handling, two file descriptors may be installed in the receiving process but not closed.

In Netty prior to versions 4.1.135.Final and 4.2.15.Final, the SslClientHelloHandler.decode() method is vulnerable to excessive memory allocation. When the ClientHello does not fit in the first record, the handler allocates a buffer of handshakeLength size, and default SniHandler/AbstractSniHandler constructors disable safeguards (maxClientHelloLength=0, handshakeTimeoutMillis=0). A 16 MiB request triggers immediate huge/unpooled allocation, retained until the channel closes.

The vulnerability in the Netty library concerns the default QUIC token handler (NoQuicTokenHandler), which unconditionally accepts any token as valid. An attacker can send an Initial packet with an arbitrary token and a spoofed victim source IP, causing the server to treat the victim as validated and send full responses without the 3× amplification limit.

In the Netty library, specifically in netty-codec-haproxy prior to versions 4.1.135.Final and 4.2.15.Final, there is a memory leak vulnerability. When decoding a PP2_TYPE_SSL TLV, if the attacker sets the TLV length below 5 bytes, an IndexOutOfBoundsException is thrown and not properly handled, causing a retained slice on the pooled cumulation buffer to never be released.

A vulnerability in Netty (netty-codec-redis) before versions 4.1.135.Final and 4.2.15.Final allows a DoS attack by sending crafted Redis payloads without `\r\n` across multiple connections. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed.