CVE-2026-75595: Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext
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.SSLRECORDHEADERLENGTH + 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.
Other sources
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Fina and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
maven/io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.2.17.Final - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.1.137.Final - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.2.17.Final
Event History
Frequently Asked Questions
Which deployments are exposed to a mutual TLS bypass?
Exposure requires SNI-based TLS context selection where a protected SNI uses clientAuth=REQUIRE, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and the application does not independently verify client certificates. Deployments that do not rely on per-SNI clientAuth as the sole gate are not described as vulnerable to this bypass.
What does an attacker need to do to trigger the issue?
An unauthenticated remote attacker must send a TLS ClientHello whose four-byte handshake header is fragmented across TLS records. This can cause the handler to select the default SslContext rather than the SNI-specific context.
How can I determine whether my configuration is at risk before patching?
Review SNI routing and compare clientAuth settings for protected SNI-specific contexts and the default SslContext. The risky configuration has clientAuth=REQUIRE only on the SNI-specific context, a default context allowing no or optional client authentication, and no application-layer client-certificate verification.
What versions contain the fix?
The issue is fixed in Netty 4.1.137.Final and 4.2.17.Final. Versions prior to those releases are affected by the described handler behavior.