CVE-2026-75595 is a critical (CVSS 9.1) flaw in Netty, the Java network framework. A crafted TLS ClientHello can make the SNI handler fall back to the default SSL context, skipping per-SNI mutual TLS. Upgrade to Netty 4.1.137.Final or 4.2.17.Final, or later, and check any setup that relies on SNI based client certificates.
What's affected
- Product: Netty (io.netty), the handler for TLS ClientHello parsing.
- Affected: Netty releases before 4.1.137.Final in the 4.1 line, and before 4.2.17.Final in the 4.2 line.
- Fixed: 4.1.137.Final and 4.2.17.Final.
- Weakness: CWE-754, improper check for unusual or exceptional conditions.
- CVSS 9.1 (critical), vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Not listed in CISA KEV.
The record spells out when this becomes a real bypass. You need per-SNI clientAuth=REQUIRE as the only mutual TLS gate, a default SslContext that uses clientAuth=NONE or OPTIONAL, and no certificate check in the application itself. If your service does not match that pattern, the impact is much smaller, but you should still upgrade.
How to check if you're exposed
Find which Netty version each service pulls in, including transitive copies.
# Maven
mvn dependency:tree -Dincludes=io.netty
# Gradle
./gradlew dependencies | grep -i "io.netty"
Look at the netty-handler artifact in particular. Then check how your server builds its SSL contexts. If it maps host names to different contexts through Netty's SNI support and relies on the per-host context to demand client certificates, you are in the risky pattern. Fat JARs and container images can hide an old copy, so scan the built artifact too, not just the source tree. The free scan at gold.safeguard.sh/scan reads your manifest in the browser.
What to do now
- Upgrade Netty to 4.1.137.Final or 4.2.17.Final, or any later release in your line. Rebuild and redeploy every service that bundles it.
- Check frameworks that shade or bundle Netty. Upgrading your own dependency does not help if a library carries its own copy.
- If you cannot upgrade yet, add an application layer check that the client certificate was actually presented on protected routes, so the TLS handshake is not your only gate.
- Review access logs for protected routes reached without a client certificate, from the days before the fix.
- Add the fixed versions to your dependency policy so older builds fail in CI.
Why it matters
The weakness is a wrong offset check. The handler reads a four byte handshake header, but it tested the wrong position first. When the header is split across TLS records, the read fails with an index error, and the error path selects the default SSL context instead of the one tied to the requested host name.
That turns a parsing mistake into an authentication decision. A route that should demand a client certificate gets served by a context that does not. This is the shape of bug where the cryptography is fine and the fallback is not. Fail closed on errors in any code that picks a security policy.
Quick check
Does this affect every Netty user?
No. The bypass needs per-SNI mutual TLS to be the only gate, with a weaker default context. Upgrade anyway, since the fix is a version bump.
Is it exploited in the wild?
The record does not mark it as a CISA Known Exploited Vulnerability, and the pages I read do not claim exploitation.
Sources
Last reviewed: 19 October 2026.
