Netty versions prior to 4.1.135.Final and 4.2.15.Final wrap any user‑supplied plain X509TrustManager inside an X509TrustManagerWrapper that ignores the SSLEngine parameter. Because the wrapper implements X509ExtendedTrustManager but does not perform hostname verification, Netty's default endpoint‑identification algorithm is never applied. Consequently a client that calls SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) will complete TLS handshakes without checking the server's hostname, allowing attackers to present fraudulent certificates and perform man‑in‑the‑middle attacks.

The vulnerability affects the Netty framework (netty:netty). All releases prior to 4.1.135.Final and 4.2.15.Final are impacted. The patched versions are 4.1.135.Final and 4.2.15.Final, which restore proper hostname verification by wrapping the supplied trust manager correctly. Any application using older Netty versions, regardless of the Java runtime, is vulnerable.

The CVSS score of 7.5 indicates a high severity and confirms that the flaw can be leveraged to compromise authentication and confidentiality. The EPSS score below 1% indicates that exploitation is not yet widespread, and the vulnerability is not listed in CISA KEV. However, the impact is far‑reaching because the defect is triggered by any client that supplies a plain trust manager through the Netty builder. An attacker can pose as a legitimate server if the client code does not enforce additional verification. The risk is therefore significant for any deployment that relies on Netty for TLS connections.