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.
Affected software
Click a technology to see all vulnerabilities affecting it.
| Platform | Package | Vulnerable versions | Fixed 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 |
References
- 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 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- Weakness (CWE)
CWE-475, CWE-754- Platform
- Java / Kotlin (Maven)
- Package
io.netty:netty-handler- Disclosed
- 08.09.2026
- Updated
- 11.10.2026 13:19
Sources and licenses
OSV / GitHub Advisory Database - GHSA-c4c3-7fpv-j4q5 - CC BY 4.0
Vulnerability history: io.netty:netty-handler
All published vulnerabilities of this package (Java / Kotlin (Maven)), newest first. Shows whether this is a one-off slip or a package that needs watching.
- Total entries
- 12
- First → latest
- 02.2020 09.2026
- Without a fix
- 0
- Exploited in attacks
- 0
Severity breakdown
- Critical 1
- High 7
- Medium 4
Disclosures per year
- 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 this entry
Know which vulnerabilities affect your application
With the DockRay integration and software inventory enabled, DockRay checks reported component versions against known vulnerabilities and notifies you about confirmed matches. Coverage depends on the supported technology and available advisory data.