Netty CVE-2026-62243

Three configuration conditions on the vulnerable application must all be true simultaneously: (1) the Netty SSL pipeline must be configured with SslProvider.OPENSSL on the client side, not the default SslProvider.JDK; (2) the trust manager supplied must be a plain X509TrustManager rather than the extended X509ExtendedTrustManager, which retains the hostname-check hook; (3) the JVM must be Java 25 or later, where Unsafe-based reflection used to inject hostname verification into the native OpenSSL path is unavailable. Additionally, the attacker must hold a network MitM position between the Netty client and its TLS peer - passive observation is insufficient; active traffic interception is required. Applications running Java 24 or earlier, using SslProvider.JDK, or supplying an X509ExtendedTrustManager are not vulnerable even if all other conditions are met.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) scores 8.7 and treats this as a straightforward high-severity network vulnerability, but the real-world attack complexity is meaningfully higher than AC:L implies. Exploitation requires three simultaneous preconditions to be true on the target: the application must use SslProvider.OPENSSL (not the default JDK provider), it must supply a plain X509TrustManager (not the extended variant), and it must run under Java 25 or later. Beyond these configuration prerequisites, the attacker must also occupy a network position capable of intercepting and relaying TLS traffic - a classic MitM requirement that further raises practical difficulty. No CISA KEV listing and no known public exploit code exist at time of analysis, and the EPSS signal is unavailable. Taken together, this is a real and critical flaw for affected deployments but is not a broad spray-and-pray vulnerability; it affects a specific intersection of library version, TLS provider choice, trust-manager implementation, and JVM version. The confidentiality impact is unambiguously high for affected applications since all data transiting the TLS session is exposed.

An attacker who has established a network position between a Java 25+ application using Netty with SslProvider.OPENSSL and a plain X509TrustManager and its upstream service intercepts the TLS handshake and presents a certificate for a different hostname signed by a CA trusted by the client. Because Netty's OpenSSL path skips hostname verification in this configuration, the certificate is accepted and the attacker can decrypt, inspect, and relay all application-layer traffic. No public proof-of-concept code exists at time of analysis, though the attack technique is well-understood within standard MitM tooling.