CVE-2026-75596: Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing
Summary
Netty's default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing superlinear (quadratic) CPU work before the handshake completes. With 4095 one-byte fragments, the handler recopies 8,386,560 bytes from only 24,579 bytes on the wire — a 341× amplification ratio.
Affected Entrypoints
- io.netty.handler.ssl.SniHandler — default constructors - io.netty.handler.ssl.SslClientHelloHandler — pre-handshake ClientHello aggregation path
Vulnerable Code Locations
- handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85 - handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75 (decode entry) - handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165 (handshakeBuffer.clear) - handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174 (writeBytes re-copy) - codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294 (cumulation retention)
Exploit Path
1. TCP connection → SniHandler → SslClientHelloHandler.decode 2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes) 3. Attacker sends thousands of tiny follow-on handshake records (1 byte each) 4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copies ALL accumulated body bytes 5. Total bytes copied = n(n+1)/2 where n = number of body bytes → quadratic 6. Event-loop CPU exhausted before SslHandler takes over
Impact
- Vulnerability Type: Inefficient Algorithmic Complexity - An unauthenticated network attacker can drive disproportionate CPU consumption on the Netty event loop - Affects all Netty deployments using SniHandler for TLS termination (the default SNI path) - No privileges, user interaction, or special configuration required - Can degrade or stall TLS connection handling for all clients on the affected event loop - The attack requires only modest bandwidth (~25 KB) to trigger significant CPU work
--- Credits
Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
maven/io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.2.17.Final - Upgrade
Upgrade
io/netty/nettyto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
io/netty/nettyto a version that resolves this vulnerability.Fixed in 4.2.17.Final - Compensating control
Mitigate the event-loop CPU exhaustion risk by using a network/transport control to reduce or rate-limit fragmented TLS ClientHello handshakes (e.g., limit the rate/size of pre-handshake records reaching Netty’s default SniHandler path) so that an unauthenticated peer cannot send thousands of tiny follow-on handshake records.
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.