CVE-2026-75596
HighCVSS 8.7Summary
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.
Risk Assessment
The risk includes TLS performance degradation, which could lead to denial of service for other clients and compromise service availability.
Recommendation
Upgrade Netty to versions 4.1.137.Final or 4.2.17.Final (or later) and monitor server load.
Original NVD description (English source)
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.