Netty SNI Routing Bypass: Fragmented ClientHello Can Trigger Fallback to Default SslContext (CVE-2026-75595)

Netty maintainers have published a critical advisory (GHSA-c4c3-7fpv-j4q5, CVE-2026-75595) affecting io.netty:netty-handler, with a public PoC already available.

What happened

According to the advisory, io.netty.handler.ssl.SslClientHelloHandler#decode contains a boundary-check bug: the guard meant to wait for the 4-byte TLS handshake header (type + length) checks the wrong buffer offset, failing to account for the preceding 5-byte record header. When an attacker fragments the initial TLS ClientHello so the first record's payload is shorter than 4 bytes, this miscalculation can trigger an IndexOutOfBoundsException while Netty is trying to parse SNI. That exception is swallowed by a generic catch (Exception) block, which then calls select(ctx, null) — silently routing the connection to the default SslContext instead of the SNI-selected one.

Why it matters

This becomes a security issue specifically where per-SNI SslContext selection is used as the sole enforcement point for mutual TLS (client-cert auth) — for example, multi-tenant TLS routing where a given hostname/route requires clientAuth=REQUIRE via its dedicated context. If the default/fallback SslContext is configured more permissively (clientAuth=NONE or OPTIONAL) and there's no secondary certificate check at the application layer, an unauthenticated attacker who sends a deliberately fragmented ClientHello can bypass the mTLS requirement for that route entirely. Any Netty-based service using SNI to gate per-hostname mTLS policy is potentially exposed; the advisory notes exploitation requires this specific configuration pattern rather than affecting all Netty TLS deployments uniformly.

What defenders should do now

• Inventory Netty-based services (proxies, API gateways, mesh sidecars, custom servers) that use SslContext selection keyed on SNI, and check whether mTLS enforcement relies solely on that per-hostname context rather than an independent peer-certificate check in application code.
• Patch/upgrade netty-handler as soon as a fixed release is available, and track the GHSA for the remediated version.
• As a mitigation until patched, consider hardening the default/fallback SslContext to also require client certificates (clientAuth=REQUIRE), removing the permissive fallback that makes this bypass exploitable.
• For hunting, look for anomalous TLS sessions terminating on mTLS-gated routes without a client certificate present, and for unusually fragmented/short initial TLS records at the network layer, which may indicate probing for this condition.
• Add application-layer verification of the peer certificate post-handshake as defense in depth, rather than trusting SNI-based context selection alone.

This is developing intel based on a same-day GHSA publication with a public PoC; details may be refined as the fix and further analysis land. See the original advisory for full technical detail: GHSA-c4c3-7fpv-j4q5.