GHSA-c4c3-7fpv-j4q5 Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext

• Maven io.netty:netty-handler: >= 4.2.0.Final, < 4.2.17.Final → fixed in 4.2.17.Final • Maven io.netty:netty-handler: < 4.1.137.Final → fixed in 4.1.137.Final

Summary A fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route's mTLS requirement. Details In `io.netty.handler.ssl.SslClientHelloHandler#decode` the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires: ```java if (handshakeLength == -1) { if (readerIndex + 4 > endOffset) { // Need more data to read HandshakeType and handshakeLength (4 bytes) return; } ``` When the first record's payload is < 4 bytes, `handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSL_RECORD_HEADER_LENGTH + 1);` leads to `IndexOutOfBoundsException `. That is caught by the generic `catch (Exception)` block, which calls `select(ctx, null)` - this is the default `SslContext`. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate. Impact SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when: • mTLS is enforced solely via per-SNI SslContext (clientAuth=REQUIRE) • the default/fallback SslContext is permissive (clientAuth=NONE/OPTIONAL) • no secondary peer-certificate verification exists at the application layer.