Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext
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.
Czego dotyczy
Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.
| Platforma | Paczka | Podatne wersje | Poprawka w wersji |
|---|---|---|---|
| Java / Kotlin (Maven) | io.netty:netty-handler | >= 4.2.0.Final, < 4.2.17.Final, < 4.1.137.Final | 4.2.17.Final, 4.1.137.Final |
Odnośniki
- https://github.com/netty/netty/security/advisories/GHSA-c4c3-7fpv-j4q5
- https://nvd.nist.gov/vuln/detail/CVE-2026-75595
- https://github.com/netty/netty/pull/17213
- https://github.com/netty/netty/pull/17217
- https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7
- https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961
- https://github.com/netty/netty
- https://github.com/netty/netty/releases/tag/netty-4.1.137.Final
- https://github.com/netty/netty/releases/tag/netty-4.2.17.Final
- Wektor CVSS
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- Słabość (CWE)
CWE-475, CWE-754- Platforma
- Java / Kotlin (Maven)
- Paczka
io.netty:netty-handler- Ujawniono
- 08.09.2026
- Aktualizacja
- 11.10.2026 13:19
Źródła i licencje
OSV / GitHub Advisory Database - GHSA-c4c3-7fpv-j4q5 - CC BY 4.0
Historia podatności: io.netty:netty-handler
Wszystkie opisane podatności tej paczki (Java / Kotlin (Maven)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.
- Wszystkich wpisów
- 12
- Pierwsza → ostatnia
- 02.2020 09.2026
- Bez poprawki
- 0
- Wykorzystywana w atakach
- 0
Rozkład istotności
- Krytyczna 1
- Wysoka 7
- Średnia 4
Ujawnienia w latach
- 2020: 4
- 2021: 0
- 2022: 1
- 2023: 1
- 2024: 0
- 2025: 1
- 2026: 5
-
Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext ten wpis
Dowiedz się, które podatności dotyczą Twojej aplikacji
Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.