CVE-2026-75596 in Netty
Summary
by MITRE • 08/20/2026
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, 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. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Netty, specifically within the io.netty.handler.ssl.SniHandler component prior to versions 4.1.137.Final and 4.2.17.Final, represents a significant performance degradation flaw rooted in inefficient memory management during the TLS handshake process. As an asynchronous, event-driven network application framework, Netty relies heavily on efficient handling of I/O operations to maintain low latency for concurrent connections. The core technical flaw resides in the SslClientHelloHandler#decode method, which is invoked when processing incoming SSL/TLS records. Specifically, the default constructors for the Server Name Indication handler utilize a pre-handshake ClientHello aggregation path that fails to optimize buffer handling. When an unauthenticated remote peer initiates a connection by advertising a large ClientHello message and subsequently fragments its body into thousands of tiny TLS records, the framework triggers a quadratic CPU workload on the event loop thread. This inefficiency arises because each additional record causes the system to execute handshakeBuffer.clear() followed by writeBytes(), effectively recopying all previously received bytes for every new fragment processed.
This architectural flaw leads to severe operational impacts characterized by resource exhaustion and service degradation. Since Netty typically uses a single-threaded or limited thread-pool event loop model, consuming excessive CPU cycles on the aggregation of fragmented handshake data directly blocks other I/O operations. An attacker can exploit this behavior through a denial-of-service attack vector by sending numerous small TLS records containing large ClientHello payloads. The resulting quadratic time complexity means that as the number of fragments increases, the processing time grows exponentially rather than linearly. This not only stalls the connection establishment for the attacking client but also degrades the performance and responsiveness for all other legitimate clients connected to the same Netty server instance, potentially causing timeouts or complete unavailability of services hosted on the affected infrastructure.
From a security classification perspective, this issue aligns with CWE-400: Uncontrolled Resource Consumption, as the application fails to limit the resources consumed by an external input stream. Furthermore, it maps to MITRE ATT&CK technique T1496: Resource Hijacking, where attackers leverage computational resources of targeted systems for their own purposes or to disrupt availability. The vulnerability highlights a critical gap in buffer management strategies within network frameworks when dealing with fragmented protocol data units. It underscores the importance of implementing efficient aggregation mechanisms that avoid redundant memory copies and ensure linear time complexity regardless of fragment count during handshake phases.
Mitigation requires immediate upgrading to Netty version 4.1.137.Final or later for the 4.1.x branch, or version 4.2.17.Final and later for the 4.2.x branch. These releases address the underlying inefficiency in the SslClientHelloHandler by optimizing how ClientHello data is aggregated from multiple TLS records. For organizations unable to upgrade immediately due to dependency constraints, applying rate limiting on new connections or implementing strict size limits on initial handshake messages can help mitigate the impact of such attacks. Additionally, monitoring CPU usage patterns associated with SSL/TLS handshakes may serve as an early detection mechanism for exploitation attempts targeting this specific vulnerability in legacy systems.