CVE-2026-45416: Netty TLS Memory Exhaustion Denial of Service

Technical summary

CVE-2026-45416 is a resource exhaustion vulnerability in Netty's SslClientHelloHandler.decode() method. The handler reads a 24-bit TLS handshake length field from incoming ClientHello records and allocates a buffer of that size via ctx.alloc().buffer(handshakeLength). A length-validation guard at line 140 checks if handshakeLength > maxClientHelloLength && maxClientHelloLength != 0; however, the commonly-used SniHandler and AbstractSniHandler constructors initialize maxClientHelloLength to 0 by default, effectively disabling the guard. With no maximum enforced, an attacker can specify a handshakeLength of 16 MiB or larger. Because this exceeds the default pooled chunk size (typically 16 MiB), Netty performs an immediate unpooled allocation that consumes significant heap memory. The buffer is retained by the handler until the channel closes, allowing a small number of crafted connections to exhaust available memory. The fix in versions 4.1.135.Final and 4.2.15.Final ensures that default maxClientHelloLength values are properly set and enforced.

Business impact

Organizations running Netty-based TLS servers—particularly those using SNI for multi-domain hosting—face a straightforward denial-of-service risk. An attacker can flood a server with large ClientHello messages, exhausting heap memory and causing the application to crash or become unresponsive. This affects availability of critical services such as API gateways, load balancers, reverse proxies, and other protocol-handling infrastructure built on Netty. Recovery requires manual intervention (service restart) and leaves no window for graceful degradation. The impact scales with the number of concurrent connections an attacker can establish, making this particularly dangerous in cloud or multi-tenant environments where connection limits may be high.

Affected systems

Netty versions prior to 4.1.135.Final (4.1.x branch) and 4.2.15.Final (4.2.x branch) are affected. Any application embedding Netty for TLS/SSL protocol handling is in scope, especially those using SniHandler, AbstractSniHandler, or custom handlers that initialize the default maxClientHelloLength parameter. This includes web servers, API gateways, reverse proxies, message brokers, and other network services. Legacy projects on older 4.0.x branches are also vulnerable if they perform similar TLS ClientHello parsing without proper resource limits.

Exploitability

This vulnerability requires only network access and no authentication or user interaction. An attacker need only establish a TLS connection and transmit a ClientHello with a large declared handshake length to trigger buffer allocation. No valid certificate, encryption, or protocol completion is necessary; the memory exhaustion occurs during the initial handshake parsing. Exploitation is trivial to automate and can be launched from a single machine or distributed across multiple sources. The default configuration of common Netty TLS handlers makes this a low-barrier attack. However, successful exploitation depends on the attacker's ability to sustain multiple concurrent connections and on the target's current memory headroom.

Remediation

Upgrade to Netty 4.1.135.Final or later (for the 4.1.x line) or Netty 4.2.15.Final or later (for the 4.2.x line). These versions enforce proper maxClientHelloLength defaults and validation. Organizations unable to upgrade immediately should consider network-level mitigations: implement connection-rate limiting, establish per-connection bandwidth caps, monitor for unusually large TLS handshakes, and ensure adequate heap memory headroom with alerting thresholds. Reverse proxy or load balancer rules can filter oversized ClientHello payloads before they reach the Netty application.

Patch guidance

Apply patches from the Netty project as follows: upgrade the Netty dependency to version 4.1.135.Final or newer (4.1.x users) or 4.2.15.Final or newer (4.2.x users). Verify the version bump in your build configuration (Maven pom.xml, Gradle build.gradle, etc.) and confirm that no custom code overrides the default maxClientHelloLength initialization. Test the patched version in a staging environment with your existing TLS load to ensure compatibility. Pay particular attention to any custom SniHandler or SslClientHelloHandler subclasses that may have been written to work around the missing defaults; those may need revision post-patch.

Detection guidance

Monitor Netty application logs for repeated connection resets or handler exceptions during ClientHello processing. Track heap memory usage patterns: look for sharp, unexplained spikes coinciding with TLS connection bursts. Enable Java GC logging to detect full garbage collections or out-of-memory conditions. At the network level, use packet inspection to identify ClientHello records with unusually large declared handshake lengths (e.g., > 64 KiB). Set up alerts on failed TLS handshakes and connection timeouts. A sustained stream of connections each declaring multi-megabyte handshakes is a strong indicator of exploitation.

Why prioritize this

This vulnerability merits prompt patching because: (1) it is a network-accessible, unauthenticated denial-of-service attack requiring minimal attacker sophistication; (2) the default configuration of popular Netty TLS handlers leaves deployments exposed without any additional configuration steps; (3) Netty is pervasive in Java infrastructure (API gateways, message brokers, service meshes); and (4) exploitation causes immediate, visible service disruption. While the CVSS score of 7.5 reflects the availability impact and low attack complexity, the real-world blast radius is large due to Netty's ubiquity and the ease of triggering the flaw.

Risk score, explained

The CVSS 3.1 score of 7.5 (High) reflects: Network-accessible attack vector (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), unchanged scope (S:U), and high availability impact (A:H). The score appropriately emphasizes that this is a trivial-to-exploit, remotely-triggerable denial of service. However, confidentiality and integrity are unaffected (C:N/I:N), and the attack requires some degree of resource commitment (sustained connections) rather than a single packet. Organizations should treat this as HIGH priority given Netty's widespread use, but should not overweight it relative to remote code execution flaws of similar CVSS score.

Frequently asked questions