CVE-2026-75596: Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nettyto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
nettyto a version that resolves this vulnerability.Fixed in 4.2.17.Final
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Netty versions before 4.1.137.Final or 4.2.17.Final that use the default io.netty.handler.ssl.SniHandler constructors are affected. The vulnerable processing occurs during pre-handshake SNI parsing.
What does an attacker need to do to trigger the resource consumption?
An unauthenticated remote peer must connect and send a large TLS ClientHello body fragmented across thousands of very small TLS records. This causes repeated copying of previously received ClientHello bytes and quadratic CPU work on the event loop before the TLS handshake finishes.
Is the default configuration affected?
Yes. The affected path is used by the default SniHandler constructors, so no special SNI parser configuration is required for exposure.
What is the impact on a running service?
The excessive pre-handshake processing can consume event-loop CPU and degrade TLS handling for other clients. The condition can be triggered before authentication or completion of a TLS handshake.
What versions contain the fix?
Upgrade to Netty 4.1.137.Final or 4.2.17.Final. Versions prior to those releases are affected.