CVE-2021-21295

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

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.