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.
Software afectado
Haz clic en una tecnología para ver todas sus vulnerabilidades.
| Plataforma | Paquete | Versiones vulnerables | Corregida en |
|---|---|---|---|
| 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 |
Referencias
- 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
- Vector 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- Debilidad (CWE)
CWE-475, CWE-754- Plataforma
- Java / Kotlin (Maven)
- Paquete
io.netty:netty-handler- Publicada
- 08.09.2026
- Actualizado
- 11.10.2026 13:19
Fuentes y licencias
OSV / GitHub Advisory Database - GHSA-c4c3-7fpv-j4q5 - CC BY 4.0
Historial de vulnerabilidades: io.netty:netty-handler
Todas las vulnerabilidades publicadas de este paquete (Java / Kotlin (Maven)), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.
- Entradas en total
- 12
- Primera → última
- 02.2020 09.2026
- Sin corrección
- 0
- Explotada en ataques
- 0
Distribución por gravedad
- Crítica 1
- Alta 7
- Media 4
Divulgaciones por año
- 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 esta entrada
Identifica las vulnerabilidades de tu aplicación
Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.