CVE-2026-50010: Netty TLS Hostname Verification Bypass with Custom Trust Managers

Technical summary

The vulnerability exists in SimpleTrustManagerFactory.engineGetTrustManagers() and related code paths that wrap user-provided X509TrustManager implementations. The wrapper extends X509ExtendedTrustManager but incorrectly implements the 3-argument checkServerTrusted(chain, authType, SSLEngine) method by discarding the SSLEngine parameter and delegating to the 2-argument variant. Because the wrapper object now IS-A X509ExtendedTrustManager, neither SunJSSE's AbstractTrustManagerWrapper nor Netty's OpenSslX509TrustManagerWrapper will perform the re-wrapping necessary to inject endpoint identification. This bypasses the endpointIdentificationAlgorithm="HTTPS" setting that Netty 4.2 configures by default, resulting in no hostname verification when a custom trust manager is supplied via SslContextBuilder.forClient().trustManager().

Business impact

Organizations relying on Netty for TLS clients—particularly those using custom certificate trust managers for internal PKI or certificate pinning—face exposure to man-in-the-middle attacks. Attackers on the network path could intercept HTTPS connections and present valid certificates for unrelated domains, potentially compromising the confidentiality and integrity of data in transit. Affected deployments appear secure but lack the hostname verification layer they expect.

Affected systems

Netty versions prior to 4.1.135.Final and 4.2.15.Final are vulnerable. Any application using Netty's SslContextBuilder with a custom X509TrustManager is at risk. This includes microservices, API clients, proxy servers, and other Java applications that perform outbound TLS connections with custom trust store logic.

Exploitability

Exploitation requires network access to intercept traffic between the vulnerable client and its destination server. No authentication, user interaction, or special privileges are needed; an attacker on the network path (or controlling DNS/routing) can present a valid certificate for any domain and the client will accept it. The barrier to exploitation is moderate—it requires either compromised network infrastructure or a position on the data path, but once achieved, attacks are straightforward.

Remediation

Upgrade to Netty 4.1.135.Final or later for the 4.1 branch, or to 4.2.15.Final or later for the 4.2 branch. These versions correct the wrapping logic to ensure endpoint identification is properly applied even when custom trust managers are supplied. After patching, verify that your SslContextBuilder configuration uses the updated code paths.

Patch guidance

Apply patches from the Netty project: upgrade to version 4.1.135.Final (4.1.x users) or 4.2.15.Final (4.2.x users) as your dependency management allows. Confirm the patched version is in use by checking your dependency resolution tools (Maven, Gradle, etc.). Testing should include verifying that clients reject certificates with hostname mismatches, which can be validated using test TLS servers with intentionally mismatched certificate names.

Detection guidance

Review application code for uses of SslContextBuilder.forClient().trustManager(customTrustManager). Examine build artifacts (JAR manifests, Maven dependency trees) to confirm Netty version and identify which applications embed vulnerable versions. Runtime detection is difficult without TLS inspection, but security monitoring for unexpected certificate acceptance or HTTPS errors may provide indirect signals. Consider deploying a proxy or TLS gateway that enforces hostname verification independently.

Why prioritize this

HIGH severity due to the high CVSS score (7.5) reflecting confidentiality impact and network accessibility. The vulnerability is silent—affected applications appear to validate certificates but do not. Organizations using Netty for outbound TLS connections with custom trust managers should prioritize patching, particularly if those connections traverse untrusted networks or are exposed to hostile environments.

Risk score, explained

CVSS 3.1 score of 7.5 (HIGH) reflects: AV:N (network-accessible attack vector), AC:L (low complexity—no special conditions required), PR:N (no privileges needed), UI:N (no user interaction), S:U (scope unchanged), C:H (high confidentiality impact—MITM can eavesdrop), I:N (integrity is not scored as violated by this vector, though in practice MITM enables tampering), A:N (availability unaffected). The score appropriately captures the exposure of encrypted traffic to interception.

Frequently asked questions