CVE-2026-62380

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