Listen to this Post
The vulnerability resides in Netty’s SNI (Server Name Indication) processing logic, specifically within the `SslClientHelloHandler.decode()` method. When a TLS ClientHello message does not fit entirely in the first record, the handler reads the 24‑bit handshake length field (handshakeLength) and immediately allocates a new `ByteBuf` of that size using ctx.alloc().buffer(handshakeLength).
By default, the commonly used constructors of `SniHandler` and `AbstractSniHandler` set `maxClientHelloLength = 0` and handshakeTimeoutMillis = 0. This disables the length guard that would normally reject an oversized ClientHello and also prevents any handshake timeout from being scheduled.
An attacker can therefore send a deliberately crafted TLS ClientHello that is split across multiple records, where the handshake length field indicates a value up to 16 MiB (the maximum allowed by the TLS specification). Because the guard is disabled, the code proceeds to allocate a buffer of that size – 16 MiB – for every such connection.
The allocated buffer is retained in the handler until the channel is closed. If an attacker opens many connections (e.g., a SYN flood), each connection forces a 16 MiB allocation. With a modest number of connections, the server’s heap memory can be exhausted, leading to a denial‑of‑service (DoS) condition.
Critically, the attack requires only nine attacker‑controlled bytes: the five‑byte TLS record header (content type, version, and length) and the four‑byte handshake header (type and three‑byte length). The rest of the record can be arbitrary padding. The vulnerability affects all Netty versions that use the vulnerable constructors, including 4.1.x up to 4.1.134.Final and 4.2.x from 4.2.0.Final to 4.2.14.Final.
DailyCVE Form:
Platform: Netty (io.netty:netty-handler)
Version: 4.1.134.Final and earlier, 4.2.0.Final to 4.2.14.Final
Vulnerability : Pre-allocation of 16 MiB from 9 attacker bytes
Severity: High
date: 2026-06-08
Prediction: 2026-06-15
What Undercode Say:
Analytics: The vulnerability (CVE-2026-45416) was publicly disclosed on 2026-06-08 via the GitHub Advisory Database. It is classified as “High” severity because a remote, unauthenticated attacker can trigger excessive memory consumption with minimal bandwidth.
Check your Netty version:
mvn dependency:tree | grep netty-handler
Simulate the attack with a Python script that sends a fragmented ClientHello with a large handshake length:
import socket
def send_malicious_clienthello(host, port):
TLS record header: content_type=22 (handshake), version=0x0303 (TLS 1.2), length=0x0100 (256 bytes)
record_header = bytes([22, 0x03, 0x03, 0x01, 0x00])
Handshake message: type=1 (ClientHello), length=0x010000 (1,048,576 bytes)
handshake_header = bytes([1, 0x01, 0x00, 0x00])
Malformed ClientHello with large declared length
payload = record_header + handshake_header + b'A' 256
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((host, port))
sock.send(payload)
sock.close()
if <strong>name</strong> == "<strong>main</strong>":
send_malicious_clienthello("target.example.com", 443)
Exploit:
An attacker need only establish a TCP connection to a server that uses the vulnerable `SniHandler` (the default configuration). The attack packet contains a TLS record that declares a handshake message length of up to 16 MiB. Because the guard is disabled and no timeout is active, the server allocates a 16 MiB buffer for that connection. Repeating this with many connections (e.g., a SYN flood) rapidly exhausts the Java heap, causing the server to become unresponsive or crash due to OutOfMemoryError.
Protection:
- Upgrade Netty to version 4.1.135.Final or 4.2.15.Final, where the `maxClientHelloLength` guard is enabled by default and a handshake timeout is scheduled.
- If upgrading is not immediately possible, manually configure the handler with a non‑zero `maxClientHelloLength` (e.g., 4096) and a
handshakeTimeoutMillis > 0:SniHandler handler = new SniHandler(mapping, 4096, 3000);
- Deploy a reverse proxy (e.g., HAProxy, Nginx) that validates TLS ClientHello lengths before forwarding traffic to the Netty backend.
Impact:
- Denial of Service (DoS): An unauthenticated remote attacker can exhaust heap memory by opening a moderate number of connections. A typical server may crash after only a few hundred connections, each consuming 16 MiB.
- Resource exhaustion: The allocated buffers remain pinned until the channel closes, prolonging the DoS effect even after the attacker stops sending data.
- No privilege escalation: The vulnerability does not allow code execution or privilege escalation; it is strictly a resource‑exhaustion issue.
🎯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
