CVE-2026-75596 is an algorithmic complexity flaw (CWE-407) in the default SniHandler of Netty. A peer can send a large ClientHello in thousands of tiny records and cause quadratic CPU work before the handshake finishes. The record rates it High at 7.5. Netty 4.1.137.Final and 4.2.17.Final fix it.
What's affected
The record says Netty before 4.1.137.Final, and before 4.2.17.Final on the 4.2 line, is affected. Netty published release notes for both fixed versions. The relevant code is the pre-handshake ClientHello aggregation path in SslClientHelloHandler, used by the default SniHandler constructors.
You are exposed if your service terminates TLS with Netty and uses the SniHandler, which is common for servers that host several domains behind one port. Services that use Netty only as a client, or use another TLS configuration, are less likely to be affected.
The record scores it 7.5 (High): network access, no privileges, and high availability impact. We did not find a conflicting severity in the pages we read.
How to check if you're exposed
Netty is usually a transitive dependency, so list the resolved versions.
mvn dependency:tree -Dincludes=io.netty
./gradlew dependencies | grep netty
Look at netty-handler in particular, which holds the SNI code. Some products bundle Netty in a shaded jar or a container image that these commands do not show, so for those scan the built artifact or the image, or read the vendor's release notes. Then ask whether your service accepts TLS connections from untrusted clients directly.
What to do now
- Upgrade Netty to 4.1.137.Final or later, or 4.2.17.Final or later, depending on your line.
- If Netty arrives through a framework, upgrade the framework or override the managed version, and confirm with the dependency tree.
- Put a TLS terminating proxy or load balancer in front of public services, so tiny record floods are handled by hardened software.
- Set handshake timeouts so that a slow sender is dropped quickly.
- Alert on event loop CPU saturation.
Why it matters
The weakness is inefficient algorithmic complexity, CWE-407. The record explains the mechanism: for every additional TLS record, the handler clears a buffer and copies all of the previously received body bytes again. If an attacker spreads a large ClientHello across thousands of tiny records, the total copying grows with the square of the number of records, and it happens on the event loop that also serves other connections.
An event loop that is busy copying cannot answer anyone else, so one client can degrade the whole listener before any TLS handshake has completed or any certificate has been checked. That is why no login or special position is needed. Handshake timeouts and limits on record counts are the general defences, and the upgrade is the direct one. KEV status is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does it matter if a load balancer terminates TLS?
If the load balancer, and not Netty, terminates TLS, this code path is not exposed to the internet. Upgrade anyway for internal listeners.
Is this related to CVE-2026-73508?
Both are Netty issues, but this one concerns TLS handshakes and that one concerns the DNS codec. They are fixed in different releases, so check both.
Sources
Last reviewed: 18 October 2026.
