CVE-2026-75595: Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty.handler.ssl.SslClientHelloHandlerto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
io.netty.handler.ssl.SslClientHelloHandlerto 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.