CVE-2026-75595 is being classified as an offset parsing bug, but that framing obscures the real vulnerability. The actual failure is in the exception handling path: when SNI context selection fails due to the buffer miscalculation, the handler calls select(ctx, null), silently falling back to the default SslContext. If that default has clientAuth=NONE or OPTIONAL while the intended SNI-bound context required REQUIRE, you have a complete authentication bypass on connections that should have been rejected.
This is a defense-in-depth failure, not merely a coding error. The offset fix is correct and necessary, but it only closes one trigger for the fallback path. Any exception in the SNI routing logic — whether from malformed input, timing edge cases, or future bugs — can still collapse the security boundary. The dangerous configuration is not exotic: it emerges naturally from tenant isolation on shared TLS termination, where you need clientCert=REQUIRE for some SNI hosts and clientCert=NONE for others. This is operationally correct and widely deployed. The problem is that this architecture creates a single point of failure where any context selection exception collapses both authentication postures to the permissive default.
You should verify whether your Netty deployment uses SNI-based context switching with divergent clientAuth settings across contexts. If it does, audit your exception handling paths in SslClientHelloHandler and surrounding code — any path that selects the default context on error is a potential bypass. The fix in 4.1.137.Final addresses the offset calculation, but you should treat the exception handler itself as a security boundary. Consider fail-closed behavior for context selection failures: reject the connection rather than fall back, or at minimum log the fallback as a security event requiring immediate triage.
The deeper question is whether your architecture depends on TLS negotiation as a single gate. If so, add application-layer certificate validation that runs regardless of clientAuth settings — make the application explicitly verify client certificates for protected resources, independent of what the TLS layer decided. This compensating control survives future bugs in the SNI routing layer. Organizations running this configuration should treat the library upgrade as urgent but recognize that the architectural exposure persists until the fail-open exception path is explicitly hardened.