CVE-2026-62243

High [CVE-2026-62243] TLS hostname verification bypass via OpenSSL client path misconfiguration

CVE-2026-62243Source published Aug 22, 2026Source updated Aug 22, 2026

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. This could lead to sensitive information disclosure. Red Hat products ship io.netty:netty-handler as a transitive dependency across multiple middleware and platform products. While the CVSS score reflects the severity of a successful…

Affected products in this advisory

• Red Hat AMQ Broker 7.13.6
• Red Hat AMQ Broker 7.14.1
• Red Hat build of Apache Camel 4.18.4 for Spring Boot 3.5.16
• Red Hat build of Keycloak 26.4.16

23 more entries in the full advisory.

Source-reported affected versions

• 4.2.0
• 4.2.16
• 4.1.136

Source-reported fixed versions

• 4.2.17
• 4.1.137
• netty-handler
• rhbk/keycloak-operator-bundle:26.4.16-2

46 more entries in the full advisory.

Mitigation guidance

• This vulnerability only affects applications that explicitly configure Netty to use the OpenSSL TLS provider (SslProvider.OPENSSL). The following mitigations can reduce exposure without applying a patch: 1) Use the default JDK SSL provider — Do not configure SslProvider.OPENSSL in your Netty SslContext setup. The default JDK SSL provider (SslProvider.JDK) is not affected by this vulnerability. Most applications use the JDK default unless explicitly overridden. 2) Use X509ExtendedTrustManager — If the OpenSSL provider is required, ensure the configured trust manager extends X509ExtendedTrustManager rather than the plain X509TrustManager interface. The extended variant performs hostname verification independently of the Netty wrapping logic. 3) Run on Java 24 or earlier — The vulnerable code path only triggers on Java 25+ where sun.misc.Unsafe-based trust-manager wrapping is unavailable. Running on earlier Java versions (e.g., Java 21 LTS) means the wrapping works correctly and hostname verification stays enabled.