CVE-2026-42577
HighSummary
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.
Risk Assessment
The organization may experience performance issues, including high CPU usage, which can lead to service degradation and impact application availability.
Recommendation
It is recommended to upgrade Netty to version 4.2.13.Final or later to mitigate this vulnerability.
Other vulnerabilities in Netty
See all- CVE-2026-42583High
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.
- CVE-2016-4970High
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).
- CVE-2026-75595Critical
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.
- CVE-2026-56817Critical
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.
- CVE-2026-76816Low
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.
- CVE-2026-62380High
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.
- CVE-2026-62243High
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.
- CVE-2026-75596High
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.
- CVE-2026-59903Medium
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.
- CVE-2026-59902High
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.
Original NVD description (English source)
Netty is an asynchronous, event-driven network application framework. From 4.2.0.Final to 4.2.13.Final , Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread. This vulnerability is fixed in 4.2.13.Final.