Netty: client TLS silently skips hostname verification when a plain X509TrustManager is supplied

Impact

Netty wraps a user-supplied plain X509TrustManager in a class that extends X509ExtendedTrustManager but throws away the SSLEngine, so neither the JDK nor Netty's own OpenSSL wrapper adds endpoint identification afterwards. A client built with SslContextBuilder.forClient().trustManager(...) therefore validates the certificate chain but never checks that the hostname matches - even in 4.2, where endpoint identification is supposed to be on by default. Anyone able to intercept the connection and present a certificate signed by a CA in the trust store can read and alter the traffic. Netty sits under a large amount of JVM-based control-plane and storage tooling that runs alongside GPU fleets, so the practical exposure is service-to-service TLS between cluster components being downgraded to no-hostname-check.

Who can reach it

A network attacker positioned between a Netty-based TLS client and its server, holding any certificate the client's trust store accepts. No credentials on the target service are required; the flaw is in the client side of the handshake.

What to do

Upgrade Netty to 4.1.135.Final or 4.2.15.Final, or take the Red Hat errata for the affected Quarkus, Camel, Cryostat and Data Grid builds, then restart each JVM service that embeds it. This is a library bump plus a rolling restart of the affected daemons - no node reboot.

References

Related entries

• Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but neverCVE-2026-52974 · Linux kernel (net/tls)High
• OpenSSL DTLS: buffering future-epoch records retains a full 16 KB read buffer each, ~1200x memory amplificationCVE-2026-54874 · OpenSSL DTLS record layer (future-epoch record buffering during handshake)High
• OpenSSL: memory leak per handshake when a server staples an OCSP response with no entriesCVE-2026-54876 · OpenSSL X.509 verification (OCSP stapled-response check, X509_V_FLAG_OCSP_RESP_CHECK)High
• libssh: incorrect AES-GCM finalization removes integrity protection on SSH sessionsCVE-2026-59847 · libssh (AES-GCM finalization check, OpenSSL backend)High
• Xen (vRTC): Out-of-bounds read in vRTC emulation - hypervisor memory disclosure to a guestCVE-2026-62430 · Xen (vRTC)High
• OpenSSL: crafted CMS message causes an 8-byte out-of-bounds heap write during CMS_decrypt()CVE-2026-63072 · OpenSSL CMS decryption (AES-WRAP-PAD key unwrap output buffer)High