CVE-2026-50010

What it actually does

Netty clients that build TLS contexts with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` can silently skip hostname verification. The flaw occurs because Netty wraps a plain `X509TrustManager` in an `X509ExtendedTrustManager` wrapper whose `checkServerTrusted(chain, authType, SSLEngine)` path discards the `SSLEngine` and delegates to the older two-argument trust check. Because the resulting object already appears to be an `X509ExtendedTrustManager`, JSSE/OpenSSL wrapper logic does not add endpoint-identification handling. As a result, a certificate chain may be trusted while the certificate identity does not match the server hostname, allowing TLS connections to succeed against an impersonated endpoint. The primary technical impact is loss of server authentication and confidentiality for affected Netty-based clients; integrity and availability are not directly affected by the vulnerability itself.

Why it matters to the business

Applications using affected Netty versions for outbound TLS connections may trust the wrong server if an attacker can position themselves on the network path, influence DNS, abuse a proxy path, or otherwise redirect traffic. This can expose API tokens, credentials, session data, customer data, or internal service traffic intended for a legitimate endpoint. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it is still important because Netty is a widely used networking framework and the bug can affect many downstream applications that rely on custom trust managers.

How an attack unfolds

An attacker first needs a way to place themselves between a vulnerable Netty client and the intended TLS server, such as through hostile Wi-Fi, compromised routing, malicious proxying, DNS manipulation, or control of an adjacent network segment. The attacker then presents a TLS certificate chain that the application’s custom plain `X509TrustManager` accepts, but whose subject or subject alternative name does not match the hostname the client intended to reach. In vulnerable Netty versions, the wrapped trust manager validates the chain but does not perform endpoint identification using the `SSLEngine`, so the hostname mismatch is not rejected. The Netty client completes the TLS handshake with the attacker-controlled endpoint and may send sensitive requests, credentials, tokens, or application data to the wrong server. Exploitation does not require authentication or user interaction, but it does require a practical traffic interception or redirection opportunity and a certificate chain accepted by the configured trust manager.

How to fix it

Upgrade Netty to a patched release: `4.1.135.Final` or later for the 4.1.x line, or `4.2.15.Final` or later for the 4.2.x line. Review dependency trees because Netty is often included transitively through RPC, HTTP, messaging, cloud, database, or service-framework libraries. Where immediate upgrade is not possible, avoid passing a plain `X509TrustManager` to `SslContextBuilder.forClient().trustManager(...)`; use a correctly implemented `X509ExtendedTrustManager` that performs endpoint identification for `SSLEngine` and `Socket` paths, or rely on standard trust manager configuration that preserves hostname verification. Add integration tests that verify TLS connections fail when the certificate is valid but issued for the wrong hostname. Do not mitigate by disabling certificate validation, using permissive trust managers, or accepting all hostnames.

How to confirm the fix worked

Confirm that all deployed artifacts resolve Netty to `4.1.135.Final` or later, or `4.2.15.Final` or later. Use build tooling such as Maven `dependency:tree`, Gradle `dependencies`, SBOM scanners, container image scanners, and runtime classpath inspection to find embedded or shaded Netty versions. Validate behavior with a negative TLS test: configure a trusted test certificate for one hostname, connect with a different hostname, and confirm the Netty client rejects the connection with a hostname-verification or certificate-validation failure. Review code for `SslContextBuilder.forClient().trustManager(...)` patterns that pass custom plain `X509TrustManager` instances. For high-assurance validation, inspect TLS client configuration and tests to ensure endpoint identification remains enabled and the `SSLEngine`-aware trust path is exercised.

Typical attack path

1. Identify an application using vulnerable Netty TLS client code with a custom plain `X509TrustManager`.
2. Obtain a network position or traffic redirection capability between the client and its intended TLS destination.
3. Present a TLS certificate chain that the application trust manager accepts but that does not match the requested hostname.
4. Allow the vulnerable Netty client to complete the TLS handshake because hostname verification is skipped.
5. Capture, relay, or manipulate sensitive application traffic sent over the incorrectly trusted TLS connection.

How to detect it

There is no reliable universal log entry that proves exploitation because the vulnerability causes missing hostname verification rather than a distinctive crash or error. To assess possible prior exploitation, combine exposure analysis with network and certificate telemetry. Identify applications using vulnerable Netty versions and custom trust managers, then review outbound TLS connection logs, proxy logs, DNS logs, EDR network events, service mesh telemetry, and packet-capture metadata for unexpected destinations, sudden DNS resolution changes, unusual proxy paths, certificate subject or SAN mismatches, unexpected certificate issuers, or certificate changes for sensitive endpoints. Look especially for successful TLS sessions to IPs or hosts not normally associated with the intended service, connections following DNS/proxy configuration changes, and traffic on untrusted networks. If TLS interception, hostile routing, or suspicious certificate presentation is suspected, investigate application logs for authentication failures, token reuse, anomalous API responses, and downstream account activity; rotate credentials that may have been transmitted by affected clients. Because no KEV listing, no ransomware association, and no known mature public exploit are reported for this input, prioritize detection around high-value clients and environments where network interception is plausible.

What your security team should do

• Inventory applications, services, agents, and client libraries that include Netty, including transitive and shaded copies.
• Prioritize internet-facing, cross-network, proxy-using, service-to-service, and credential-bearing clients that use custom TLS trust managers.
• Upgrade affected dependencies to Netty `4.1.135.Final` or later, or `4.2.15.Final` or later.
• Search source code for custom `X509TrustManager` usage with `SslContextBuilder.forClient().trustManager(...)` and require secure endpoint-identification tests before release.
• Add CI/CD dependency gates to block vulnerable Netty versions from being introduced again.
• Review network telemetry for unusual TLS destinations, DNS changes, proxy changes, certificate anomalies, or unexpected issuer/subject combinations around sensitive outbound connections.
• Treat confirmed suspicious TLS redirection as a potential credential exposure event and rotate secrets that may have traversed affected clients.