CVE-2026-62243: Netty TLS Hostname Verification Bypass

CVE-2026-62243 Overview

CVE-2026-62243 is a TLS hostname verification bypass in the Netty framework (io.netty:netty-handler). Affected versions include 4.2.0.Final through 4.2.16.Final and all versions through 4.1.136.Final. The flaw activates on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is configured and Unsafe-based trust-manager wrapping is unavailable, a condition that occurs on Java 25 and later. In this state, the OpenSSL client accepts server certificates without verifying that the certificate's identity matches the requested hostname. The issue is fixed in versions 4.2.17.Final and 4.1.137.Final.

Critical Impact
A network-positioned attacker can present any valid certificate issued for a different hostname and complete the TLS handshake, enabling man-in-the-middle interception of confidential traffic.

Affected Products

io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final
io.netty:netty-handler versions through 4.1.136.Final
Applications running on Java 25 or later that use SslProvider.OPENSSL with a plain X509TrustManager

Discovery Timeline

2026-08-22 - CVE-2026-62243 published to NVD
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-62243

Vulnerability Analysis

The vulnerability is an improper certificate validation flaw classified as [CWE-297] (Improper Validation of Certificate with Host Mismatch). Netty's SslProvider.OPENSSL client path relies on wrapping a caller-supplied X509TrustManager so that hostname verification runs during the handshake. When the supplied trust manager is a plain X509TrustManager rather than an X509ExtendedTrustManager, Netty historically used sun.misc.Unsafe-based reflection to inject hostname verification behavior. Java 25 removes access to that Unsafe pathway, so the wrapping silently fails and the client falls back to certificate-chain validation without any hostname check.

The result is that any server presenting a chain trusted by the configured trust store is accepted, regardless of the Server Name Indication (SNI) or the hostname the client intended to reach. The impact is confidentiality of intercepted TLS traffic; integrity and availability are not directly affected because the attacker still requires a valid, trusted certificate for some hostname.

Root Cause

The root cause is a silent failure in the trust-manager wrapper used by the OpenSSL provider. When Unsafe-based reflection is unavailable and the application supplies a plain X509TrustManager, Netty proceeds with a trust manager that performs only chain validation. Hostname verification, normally supplied by X509ExtendedTrustManager semantics, never executes.

Attack Vector

An attacker with a network position between the Netty client and its intended server intercepts the TLS ClientHello and responds with a certificate issued for an unrelated hostname the attacker controls. Because the client skips hostname matching, the handshake succeeds and the attacker decrypts, inspects, or modifies subsequent application traffic. No user interaction, credentials, or client-side code execution are required. Detailed conditions are described in the Netty GitHub Security Advisory and the VulnCheck Advisory on Netty Bypass.

Detection Methods for CVE-2026-62243

Indicators of Compromise

Successful TLS sessions from Netty-based clients to hostnames whose presented certificate subjectAltName values do not match the destination hostname.
Unexpected outbound TLS connections from Java 25+ services to IP addresses or hostnames outside the documented allowlist.
Application logs showing successful HTTPS calls despite proxy or IDS alerts about certificate name mismatches.

Detection Strategies

Inventory Java runtime versions and Netty dependency versions across build manifests and running services; flag any process using Java 25 or later with netty-handler at or below 4.2.16.Final or 4.1.136.Final.
Perform static analysis of application code for SslContextBuilder.forClient().sslProvider(SslProvider.OPENSSL) combined with a custom X509TrustManager that does not extend X509ExtendedTrustManager.
Use TLS inspection or network telemetry to correlate destination hostname (SNI) with the certificate common name and SAN entries returned by the server.

Monitoring Recommendations

Alert on TLS handshakes where the presented certificate identity does not match the requested SNI for internal service-to-service traffic.
Track dependency updates via software composition analysis and fail builds that pin vulnerable Netty versions.
Monitor egress from Java workloads for connections to non-approved destinations, which may indicate MITM redirection.

How to Mitigate CVE-2026-62243

Immediate Actions Required

Upgrade io.netty:netty-handler to 4.2.17.Final or 4.1.137.Final in all applications and container images.
Audit application code for use of SslProvider.OPENSSL with plain X509TrustManager implementations and replace them with X509ExtendedTrustManager subclasses.
Prioritize remediation on services running Java 25 or later, where the bypass is active by default.

Patch Information

The maintainers fixed the flaw in Netty 4.2.17.Final and 4.1.137.Final. The fix ensures hostname verification runs on the OpenSSL client path regardless of the availability of Unsafe-based wrapping. Refer to the Netty GitHub Security Advisory for patch commits and release notes.

Workarounds

Switch clients from SslProvider.OPENSSL to SslProvider.JDK until the Netty upgrade is deployed, since the JDK provider performs hostname verification independently.
Supply an X509ExtendedTrustManager implementation instead of a plain X509TrustManager so hostname verification runs natively.
Run affected services on Java versions prior to 25 as a temporary measure, since Unsafe-based wrapping still succeeds there.

bash

# Configuration example: update Maven dependency to a fixed version
<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-handler</artifactId>
  <version>4.2.17.Final</version>
</dependency>