| Package | Affected versions | Patched versions |
|---|---|---|
| io.netty:netty-handler | ≥ 4.2.0.Final, < 4.2.17.Final< 4.1.137.Final | 4.2.17.Final4.1.137.Final |
| netty | ≥ 4.2.0, < 4.2.17< 4.1.137 | 4.2.174.1.137 |
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.
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.
SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when:
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free