CVE-2026-93574

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.

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.