CVE-2026-75595

Updated on 19 Aug 2026

Severity

9.1 Critical severity

Details

CVSS score
9.1
CVSS vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Overview

About vulnerability

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:

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.

Details

Fixes