Listen to this Post
Netty’s default SNI entrypoint is vulnerable to a denial-of-service attack due to an inefficient algorithmic complexity issue. The flaw exists in the pre-handshake ClientHello aggregation path used by the default `io.netty.handler.ssl.SniHandler` constructors. When processing a fragmented TLS ClientHello, the `SslClientHelloHandler.decode()` method utilizes `handshakeBuffer.clear()` and `writeBytes()` to reassemble the message. This approach re-copies all previously received body bytes for every new TLS record that arrives.
An unauthenticated remote attacker can exploit this by sending a small first TLS record that advertises a large ClientHello length, followed by the body in thousands of tiny records (e.g., 1 byte each). This forces the handler to perform a quadratic number of copy operations, as the total bytes copied equals n(n+1)/2, where `n` is the number of body bytes. For example, with 4095 one-byte fragments, the handler recopies 8,386,560 bytes from only 24,579 bytes on the wire—a 341× amplification ratio.
This CPU exhaustion occurs on the Netty event loop thread before the TLS handshake completes, effectively blocking other I/O operations and degrading or stalling TLS connection handling for all clients. The attack requires no privileges, user interaction, or special configuration and can be executed with modest bandwidth (~25 KB). The vulnerability affects Netty versions prior to 4.1.137.Final and 4.2.17.Final.
DailyCVE Form:
Platform: Netty
Version: <4.1.137.Final, <4.2.17.Final
Vulnerability: Algorithmic Complexity DoS
Severity: HIGH (CVSS 8.7)
date: 2026-08-19
Prediction: Already Patched (2026-08-19)
What Undercode Say:
The vulnerability stems from the SslClientHelloHandler‘s inefficient handling of fragmented TLS handshake records. The following commands can be used to check for vulnerable Netty versions in a project:
Check Netty version in a Maven project mvn dependency:tree | grep netty-handler Check Netty version in a Gradle project gradle dependencies | grep netty-handler Check installed Netty packages (Debian/Ubuntu) dpkg -l | grep netty Check installed Netty packages (RHEL/CentOS) rpm -qa | grep netty
The vulnerable code paths are located at:
– `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: (Educational Purposes!)
The exploit path for CVE-2026-75596 is as follows:
- Establish a TCP connection to the target Netty server using the
SniHandler. - Send a first TLS handshake record that declares a large ClientHello length (e.g., 4096 bytes).
- Transmit the ClientHello body in thousands of tiny follow-on handshake records (e.g., 1 byte each).
- For each fragment received, the `SslClientHelloHandler.decode()` method executes `handshakeBuffer.clear()` followed by
writeBytes(), which re-copies the entire accumulated body. - The total bytes copied follows a quadratic growth pattern (
n(n+1)/2), where `n` is the number of body bytes. - The event-loop CPU becomes exhausted before the `SslHandler` takes over, causing a denial of service.
Protection:
The primary protection against this vulnerability is to upgrade to a patched version of Netty:
– For Netty 4.1.x: Upgrade to version 4.1.137.Final or later.
– For Netty 4.2.x: Upgrade to version 4.2.17.Final or later.
As a defensive measure, organizations should also consider implementing monitoring for unusual CPU and memory allocation patterns, as well as connection rate limiting.
Impact:
- Vulnerability Type: Inefficient Algorithmic Complexity (CWE-407)
- 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
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
