CVE-2026-50010
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk19th percentile - higher than 19% of all known CVEs
Summary
A vulnerability in Netty where wrapping a plain X509TrustManager in X509TrustManagerWrapper bypasses hostname verification. Despite Netty 4.2 defaulting to endpointIdentificationAlgorithm="HTTPS", a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.
Risk Assessment
An attacker can perform a man-in-the-middle (MITM) attack by impersonating a trusted server, as the lack of hostname verification allows any certificate matching the trust chain to be accepted.
Recommendation
Immediately update Netty to version 4.1.135.Final or 4.2.15.Final, which contain the fix for this issue.
Original NVD description (English source)
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.