Loading vulnerability…
TLS hostname-verification bypass in Netty trust-manager handling
CVE-2026-50010 is a TLS hostname-verification bypass in Netty's netty-handler component, affecting versions before 4.1.135.Final in the 4.1 branch and before 4.2.15.Final in the 4.2 branch. SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap user-supplied plain X509TrustManager instances in X509TrustManagerWrapper, which extends X509ExtendedTrustManager. Its three-argument checkServerTrusted(chain, authType, SSLEngine) method discards the SSLEngine and invokes the delegate's two-argument method, losing the context needed for endpoint identification. Because the wrapper already implements X509ExtendedTrustManager, SunJSSE and Netty's OpenSSL trust-manager wrappers do not add the missing endpoint-identification checks. Consequently, affected clients can omit hostname verification even when the endpoint-identification algorithm is configured as HTTPS, including by default in Netty 4.2.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Affected TLS clients can accept a server certificate without verifying that it identifies the intended hostname. An attacker able to intercept or redirect a connection and present a certificate accepted by the configured trust manager could impersonate the destination server. This can expose credentials and application data or permit alteration of application traffic. The vulnerability bypasses hostname verification; it does not inherently bypass certificate-chain validation.
If you can’t patch tonight, do this now.
Until an upgrade is possible, avoid supplying a plain X509TrustManager to SslContextBuilder.forClient().trustManager(...). Use a trust-manager implementation that correctly preserves and enforces endpoint identification. Merely setting endpointIdentificationAlgorithm to HTTPS is insufficient on the affected wrapping path.
Patch, then assume compromise.
Upgrade io.netty:netty-handler to 4.1.135.Final or later in the 4.1 branch, or 4.2.15.Final or later in the 4.2 branch. For products bundling Netty, install the applicable vendor security update containing the fix rather than replacing dependencies outside the supported update process.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
58 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.