CVE-2026-62243: Netty 4.2.0 through 4.2.16 TLS Hostname Verification Bypass
Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is used and Unsafe-based trust-manager wrapping is unavailable (Java 25+). In this configuration the OpenSSL client does not perform hostname verification, allowing a man-in-the-middle attacker to present a certificate issued for a different hostname that is accepted without validation. Fixed in 4.2.17.Final and 4.1.137.Final.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.2.17.Final - Upgrade
Upgrade
io.netty:netty-handlerto a version that resolves this vulnerability.Fixed in 4.1.137.Final
Event History
Frequently Asked Questions
Which deployments are affected by this hostname-verification bypass?
Affected deployments use Netty's SslProvider.OPENSSL client path with a plain, non-extended X509TrustManager, where Unsafe-based trust-manager wrapping is unavailable. The described condition applies on Java 25+.
What does an attacker need to exploit the issue?
An attacker must be able to act as a man in the middle of the TLS connection. They can then present a certificate issued for a different hostname, which the affected OpenSSL client path accepts without hostname validation.
Are all Netty TLS clients affected?
No. The issue is specifically described for the OpenSSL client provider path under the stated trust-manager and Java 25+ conditions. The data does not indicate that other TLS provider paths are affected.
How can this be remediated?
Upgrade io.netty:netty-handler to 4.2.17.Final or later on the 4.2 line, or to 4.1.137.Final or later on the 4.1 line.