Netty EUVD-2026-63092

The vulnerability is triggered when the Netty application initializes TLS handling using the default io.netty.handler.ssl.SniHandler constructors - specifically the path through SslClientHelloHandler that aggregates TLS ClientHello messages before handshake completion. This is the standard, default configuration for SNI-based TLS routing in Netty. No authentication is required: the attack occurs entirely in the pre-handshake phase. The attacker needs only network-level TCP access to the Netty TLS port. Exploitation effectiveness scales with the degree of ClientHello fragmentation - the attacker controls the number of TLS records, amplifying CPU cost. Factors that limit exploitation: (1) applications that do not use SniHandler at all are not affected; (2) custom SniHandler subclasses or configurations that bypass the default aggregation path may not be vulnerable; (3) network-layer controls that reassemble or rate-limit TLS records before they reach Netty can reduce but not eliminate impact.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) is well-grounded: the attack is network-reachable, requires no authentication, imposes no prerequisites on the attacker, and reliably produces high availability impact. No EPSS data was provided, which limits probabilistic exploitation modeling. The vulnerability is not in CISA KEV and no public proof-of-concept has been identified at time of analysis, reducing the immediate exploitation pressure. However, the attack primitive is trivially constructable from the public description - TLS record fragmentation is a standard network-level technique - which means absence of a known POC provides limited assurance. The event-loop architecture of Netty amplifies impact: a single attacker connection can saturate CPU and degrade or deny service for all concurrent users of the same Netty instance, not just TLS connections. Any team operating an internet-facing Netty TLS endpoint should treat this as an urgent patching priority, given that the attack surface is the default constructor path and requires no special client state. The primary uncertainty is whether automated scanning tools will develop fingerprinting capabilities to reliably detect vulnerable Netty TLS endpoints at scale.

An attacker with network access to a Netty TLS port opens a TCP connection and sends a valid but oversized TLS ClientHello - padded with many TLS extensions - deliberately fragmented into thousands of 1-byte or small TLS records. For each arriving record, SslClientHelloHandler#decode clears its buffer and recopies all previously received bytes, generating CPU work proportional to the square of the number of records. With a few hundred kilobytes of ClientHello data split across thousands of records, the event loop thread spends seconds on a single connection, during which no other connection can be accepted or processed, effectively denying TLS service to all clients. No public proof-of-concept has been identified, but the technique follows standard TLS fragmentation patterns.