CVE-2026-56817

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