Netty: Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain… (CVE-2026-50010)

Netty is a network application framework used for protocol servers and clients. In versions prior to 4.1.135.Final and 4.2.15.Final, the SimpleTrustManagerFactory.engineGetTrustManagers() method wraps any user-supplied plain X509TrustManager in an X509TrustManagerWrapper that extends X509ExtendedTrustManager but implements the three-argument checkServerTrusted(chain, authType, SSLEngine) method by discarding the SSLEngine parameter and calling the two-argument delegate. Because this wrapped object is now an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's OpenSslX509TrustManagerWrapper re-wrap it to add endpoint identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, clients built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) perform no hostname verification at all. This vulnerability is patched in versions 4.1.135.Final and 4.2.15.Final.

Clients using affected Netty versions with custom plain X509TrustManager instances may not perform hostname verification during TLS handshakes, despite default settings intended to enforce it. This can lead to man-in-the-middle attacks where an attacker could impersonate a server without detection. The CVSS 3.1 base score is 7.5 (High), reflecting network attack vector, low complexity, no privileges or user interaction required, unchanged scope, high confidentiality impact, and no integrity or availability impact.

Upgrade to Netty versions 4.1.135.Final or 4.2.15.Final or later, where this issue is fixed. There is no indication of any temporary workaround or alternative mitigation. Users should ensure that custom trust managers are not used in a way that bypasses hostname verification.