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.
Betroffene Software
Klicken Sie auf eine Technologie, um alle zugehörigen Schwachstellen anzuzeigen.
| Plattform | Paket | Anfällige Versionen | Behoben in |
|---|---|---|---|
| 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 |
Verweise
- 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
- CVSS-Vektor
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- Schwäche (CWE)
CWE-475, CWE-754- Plattform
- Java / Kotlin (Maven)
- Paket
io.netty:netty-handler- Veröffentlicht
- 08.09.2026
- Aktualisiert
- 11.10.2026 13:19
Quellen und Lizenzen
OSV / GitHub Advisory Database - GHSA-c4c3-7fpv-j4q5 - CC BY 4.0
Schwachstellenhistorie: io.netty:netty-handler
Alle veröffentlichten Schwachstellen dieses Pakets (Java / Kotlin (Maven)), neueste zuerst. Zeigt, ob es ein einmaliger Ausrutscher ist oder ein Paket, das man im Auge behalten muss.
- Einträge insgesamt
- 12
- Erste → letzte
- 02.2020 09.2026
- Ohne Fix
- 0
- In Angriffen ausgenutzt
- 0
Verteilung nach Schweregrad
- Kritisch 1
- Hoch 7
- Mittel 4
Veröffentlichungen pro Jahr
- 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 dieser Eintrag
Erkennen Sie Schwachstellen in Ihrer Anwendung
Mit der DockRay-Integration und aktivierter Softwareinventarisierung prüft DockRay gemeldete Komponentenversionen auf bekannte Schwachstellen und benachrichtigt Sie über bestätigte Treffer. Die Abdeckung hängt von der unterstützten Technologie und den verfügbaren Meldungen ab.