CVE-2026-45416

What it actually does

This is a remotely triggerable denial-of-service flaw in Netty's TLS ClientHello parsing path. Before Netty 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() can trust the 24-bit TLS handshake length from an incomplete ClientHello and immediately allocate a buffer of that advertised size. Common SniHandler and AbstractSniHandler constructor paths set maxClientHelloLength=0 and handshakeTimeoutMillis=0, disabling both the length guard and timeout protection. A remote unauthenticated client can therefore send a fragmented or incomplete TLS ClientHello with an oversized handshake length, causing a large direct/unpooled memory allocation that remains retained until the channel closes. Repeated connections can exhaust memory, degrade the JVM, trigger garbage collection pressure, or crash affected services.

Why it matters to the business

Internet-facing or internal services built on affected Netty versions can be made unavailable by unauthenticated network traffic. The practical consequence is service outage, elevated latency, connection failures, JVM crashes, autoscaling churn, and possible cascading failures in systems that depend on Netty-based gateways, APIs, proxies, brokers, or application servers. Although it does not expose data or allow code execution, the low attack complexity and lack of authentication requirement make it important to remediate on externally reachable TLS listeners, especially where Netty is embedded transitively through other frameworks.

How an attack unfolds

An attacker identifies a TLS-enabled service that uses an affected Netty SNI/ClientHello handling path. The attacker opens TCP connections to the service and begins a TLS handshake. Instead of sending a normal complete ClientHello, the attacker advertises a very large TLS handshake length that does not fit in the first TLS record and leaves the handler waiting for the rest of the message. Because common Netty SNI handlers configured maxClientHelloLength and handshake timeout as zero, the affected code does not reject the oversized ClientHello or time out promptly. Netty immediately allocates a large buffer to hold the advertised ClientHello and retains it while the channel remains open. By repeating this over many connections, the attacker consumes direct or heap memory until the service becomes slow, rejects connections, throws allocation errors, or terminates.

How to fix it

Upgrade Netty to a fixed release: 4.1.135.Final or later on the 4.1.x line, or 4.2.15.Final or later on the 4.2.x line. Because Netty is commonly pulled in transitively, review application dependency trees and framework-managed versions, then force or override vulnerable Netty artifacts consistently across the application. Rebuild and redeploy all affected services after dependency updates. If immediate upgrade is not possible, reduce exposure by placing affected TLS services behind a proxy or load balancer that enforces sane TLS ClientHello size limits and handshake timeouts, restrict network access where feasible, cap per-source connection concurrency, configure aggressive idle/handshake timeouts at the edge, and monitor JVM direct memory usage closely. Application-level mitigations should not be treated as a substitute for upgrading because the vulnerable allocation occurs in the TLS/SNI parsing path.

How to confirm the fix worked

Confirm remediation by checking runtime and build-time dependency versions for all Netty modules and ensuring they resolve to 4.1.135.Final or later, or 4.2.15.Final or later. Use dependency inspection tools such as Maven dependency:tree, Gradle dependencies/dependencyInsight, SBOM scans, container image scans, and runtime classpath inspection to detect older io.netty artifacts. Validate that rebuilt artifacts and deployed containers do not include vulnerable Netty JARs. Operationally, confirm TLS endpoints remain stable under legitimate handshake load, that edge devices enforce handshake timeouts and request size limits where applicable, and that JVM direct memory does not spike abnormally during malformed or incomplete TLS handshakes. If a scanner is used, prefer authenticated software composition analysis over network-only detection because Netty is an embedded library and may not be identifiable from the network.

Typical attack path

1. Discover a TLS endpoint backed by an affected Netty version or framework that embeds affected Netty components.
2. Open one or more TCP connections to the TLS listener.
3. Send a TLS ClientHello record whose 24-bit handshake length advertises a very large message that is not fully contained in the first record.
4. Keep the connection open or repeat the pattern so allocated buffers remain retained.
5. Scale the number of concurrent connections until JVM direct memory, heap memory, or connection capacity is exhausted.
6. Cause service degradation, failed TLS handshakes, elevated error rates, or process termination.

How to detect it

To determine whether exploitation may already have occurred, review application logs, JVM logs, container logs, load balancer logs, reverse proxy logs, network telemetry, and TLS handshake metrics for the period since exposure began. Look for sudden increases in inbound TLS connections that do not complete handshakes, repeated connection resets during the ClientHello phase, abnormal growth in established or idle connections, spikes in direct memory usage, garbage collection pressure, allocation failures, and unexplained process restarts. Application logs may show Netty stack traces involving SslClientHelloHandler, SniHandler, ByteBuf allocation, direct memory exhaustion, or OutOfMemoryError. Network telemetry may show many short or stalled TLS sessions with fragmented ClientHello messages or unusually large advertised handshake lengths. Correlate these events with source IP concentration, connection-rate spikes, and service availability drops. There are no named threat actors or public active-exploitation signals provided for this issue, so absence of known actor indicators should not be used to rule out opportunistic denial-of-service attempts.

• java.lang.OutOfMemoryError: Direct buffer memory
• io.netty.util.internal.OutOfDirectMemoryError
• io.netty.handler.ssl.SslClientHelloHandler
• SslClientHelloHandler.decode
• io.netty.handler.ssl.SniHandler
• AbstractSniHandler
• failed to allocate 16777215 byte(s)
• failed to allocate 16777216 byte(s)
• Cannot reserve memory
• Direct buffer memory
• PooledByteBufAllocator
• UnpooledByteBufAllocator
• TLS handshake failed
• handshake timed out
• connection reset during TLS handshake
• ClientHello
• fragmented ClientHello
• oversized ClientHello

What your security team should do

• Prioritize inventory of externally reachable TLS services and applications that embed Netty, including services using Netty through frameworks, API gateways, brokers, RPC stacks, and reactive web servers.
• Upgrade all affected Netty dependencies to 4.1.135.Final or later, or 4.2.15.Final or later, and ensure transitive dependency overrides do not leave mixed vulnerable Netty modules on the classpath.
• Add or verify edge-layer TLS handshake timeouts, maximum ClientHello/message-size controls, idle connection limits, and per-source connection rate limits for exposed services.
• Monitor JVM direct memory, heap pressure, garbage collection pauses, connection counts, TLS handshake failures, and process restarts for affected services until remediation is complete.
• Create detection logic for bursts of incomplete or malformed TLS handshakes, unusually large advertised ClientHello lengths, and repeated direct memory allocation failures.
• Review recent availability incidents on Netty-backed services for signs of unexplained memory exhaustion or spikes in half-open/slow TLS handshakes.
• Because EPSS is currently low and there is no known KEV listing or ransomware association, treat this as a high-priority availability hardening issue rather than evidence of active exploitation, while still patching promptly due to unauthenticated network reachability.