Executive brief
Netty's TLS Server Name Indication (SNI) handler processes fragmented TLS ClientHello messages inefficiently, re-copying previously received data on each new fragment. An attacker can exploit this by sending a TLS handshake that advertises a large message size followed by thousands of tiny fragments, forcing the server to waste CPU resources reassembling the same bytes repeatedly. This can exhaust event-loop capacity and starve legitimate TLS connections from being processed, causing service degradation or denial of service.
Technical details
The vulnerability is an inefficient algorithmic complexity flaw (CWE-407) in Netty's TLS SNI and pre-handshake ClientHello handling. When `SniHandler` (default constructor) or `SslClientHelloHandler` receive fragmented TLS records advertising a large ClientHello, the code repeatedly clears and recopies accumulated message bytes on each new fragment via `handshakeBuffer.clear()` + `writeBytes()` operations. This results in O(n²) CPU work where n is the total message length. An unauthenticated network attacker can trigger this with minimal bandwidth (~25 KB) by sending a TLS record declaring 4096+ bytes of ClientHello followed by thousands of 1-byte fragments. The attack requires no privileges, authentication, or user interaction. Patches are available in netty-handler 4.1.137.Final and 4.2.17.Final.
Affected products
- Netty netty-handler >= 4.2.0.Final, <= 4.2.16.Final; <= 4.1.136.Final
Timeline
- 2026-08-19: disclosed: Published to NVD
- 2026: patched: Patches released: netty-4.1.137.Final, netty-4.2.17.Final
- 2026-09-08: advisory: GitHub Security Advisory GHSA-fccg-mwvh-qqg4 published