CVE-2026-62243: Netty's Hostname Verification Fix Undid Itself on Java 25

Netty’s OpenSSL client path silently drops TLS hostname verification on Java 25 and newer, when the application supplies a plain X509TrustManager to SslContextBuilder. The bug is CVE-2026-62243, and it is a regression in the fix for an earlier CVE in the same code path. The fix works correctly on Java 24 and below and stops working on Java 25.

What changed

CVE-2026-62243 (CWE-297, CVSS 3.1: 7.5 High) was published to NVD on August 22, 2026, tracked upstream as GHSA-p85m-gvr3-788c. It affects io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final, and versions through 4.1.136.Final. Fixed in 4.2.17.Final and 4.1.137.Final.

The regression comes from an earlier advisory, CVE-2026-50010, found that Netty’s SimpleTrustManagerFactory wrapped user-supplied X509TrustManager instances in a way that made both SunJSSE and Netty’s own OpenSslX509TrustManagerWrapper treat them as already SSLEngine-aware, skipping the wrapping step that adds hostname checks. That fix (4.1.135.Final / 4.2.15.Final) used sun.misc.Unsafe-based reflection to force the wrapping through anyway, so the OpenSSL client engine would call the three-argument checkServerTrusted(chain, authType, engine) overload instead of the two-argument one that ignores the peer hostname entirely.

Java 25 restricts default access to Unsafe. When that reflection path is unavailable, Netty falls back to OpenSslX509TrustManagerWrapper’s default implementation, which just returns the original trust manager unchanged, without an exception or log message. The wrapping silently becomes a no-op, and the connection is back to the exact behavior CVE-2026-50010 was supposed to fix.

Why it matters operationally

This affects any JVM service that builds an SslContext with SslProvider.OPENSSL and a custom (non-extended) X509TrustManager, which is a common pattern anywhere netty-tcnative is used for performance or FIPS-validated OpenSSL bindings instead of the JDK’s default JSSE provider. That includes services built directly on Netty as well as anything layered on top of it: reactor-netty-based Spring WebFlux clients, gRPC-Java’s Netty transport, and any internal service mesh sidecar or RPC client that wires in a custom trust manager for private CA validation or mTLS.

The trigger is a JDK upgrade rather than a Netty upgrade. A service can run unaffected on Netty 4.2.16.Final and Java 21 for a year, then silently lose hostname verification the day the runtime moves to Java 25, with no code change and no CI signal, because none of your test suites are asserting that a mismatched-hostname certificate gets rejected.

Checking if you’re exposed

Two things have to both be true: you’re on an affected Netty version, and you’re running on Java 25+.

# Confirm the JVM version
java -version
# openjdk version "25" ...

# Confirm the netty-handler version actually on the classpath
find ~/.m2 ~/.gradle -name 'netty-handler-*.jar' 2>/dev/null
# or, inside a running app:
jar tf app.jar | grep 'netty-handler-'

If you’re on Java 25+ with netty-handler 4.1.x below 4.1.137.Final or 4.2.x below 4.2.17.Final, and your client code looks like this:

SslContext ctx = SslContextBuilder.forClient()
    .sslProvider(SslProvider.OPENSSL)
    .trustManager(myCustomTrustManager) // plain X509TrustManager, not X509ExtendedTrustManager
    .build();

hostname verification is not happening on that connection path, regardless of endpointIdentificationAlgorithm being set to HTTPS (Netty 4.2’s default). A server presenting a valid certificate for the wrong hostname will be accepted. The fix is a version bump; there’s no config flag to restore the wrapping behavior from the earlier fix.

How KrakenKey’s flow relates

This doesn’t change anything in KrakenKey’s issuance or renewal flow, since it’s a client-side TLS library bug rather than a CA-side or ACME protocol issue. Operators running Netty-based services, especially anything using SslProvider.OPENSSL with custom trust managers for private CA or mTLS validation, should confirm their Netty and JDK versions independently of any certificate automation they have in place, since no amount of correct certificate issuance protects a client that isn’t checking the hostname on the cert it receives.