CVE-2026-50010
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk19th percentile - higher than 19% of all known CVEs
Summary
A vulnerability in Netty causes a user-supplied plain X509TrustManager to be wrapped in X509TrustManagerWrapper, which implements X509ExtendedTrustManager but discards endpoint identification. Consequently, even with default endpointIdentificationAlgorithm="HTTPS" in Netty 4.2, the client performs no hostname verification.
Risk Assessment
The organization is at risk of man-in-the-middle (MITM) attacks because the TLS client does not verify that the server certificate matches the expected hostname. This could lead to interception or modification of transmitted data.
Recommendation
Immediately update Netty to version 4.1.135.Final or 4.2.15.Final. If an update is not possible, manually enforce hostname verification in the client code.
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.