Netty QUIC Client X509TrustManager Hostname Verification Bypass (CVE-2026-50010)

CVE-2026-50010 Vulnerability Summary Vulnerability Overview Title: Incomplete Fix for CVE-2026-50010: QUIC Clients Can Still Bypass Hostname Verification via Standard X509TrustManager Severity: High - CVSS 7.5 / 10 Description: Netty version 4.2 patched a hostname verification bypass vulnerability (GHSA-c653-97wb-rcgb / CVE-2026-50010) affecting the in the package. However, a similar trust-manager logic flaw exists in the certificate verification path for QUIC in the package. Technical Details: defaults to as the endpoint identification algorithm. When an application provides a standard , only invokes the two-argument method, discarding the and information. This results in the QUIC client accepting certificate chains even when the certificate identity does not match the requested peer host. Affected Scope Affected Package: Affected Versions: Fixed Version: Confirmed Vulnerable Specific Versions: - Current 4.2 branch (commit: ) - 4.2.15.Final (commit: ) Remediation Recommended Fix: Ensure that the QUIC certificate verification path retains engine-aware endpoint identification when dealing with standard instances. Possible Implementation Directions: In , wrap standard instances in the same manner as the engine-aware trust manager support in the Netty OpenSSL client API. Alternatively, re-wrap standard instances to enable endpoint identification in the QUIC client context unless the caller explicitly disables it. Add regression test coverage: QUIC clients using a standard trust manager, explicit , and a mismatching peer host must fail certificate verification. Keep insecure trust manager factory behavior explicit so that intentional "trust all" configurations can still be distinguished from standard custom trust managers. POC Code File: Run Command: POC Logic Description: 1. Create a QUIC client context: - - Explicit - Peer host - Standard that accepts the provided certificate chain 2. Call locally using Netty test certificates. 3. The expected secure behavior is that the verification result should be non-OK, rejecting the certificate, because HTTPS endpoint identification is configured for the peer host . Observed Results (Current 4.2 Branch): Control Test (Using X509ExtendedTrustManager): This control test receives an , rejects the peer host, and passes. This isolates the bypass to the standard manager branch, rather than the test certificates or callback pipeline. Observed Results (4.2.15.Final): Why This Is Not Intended Behavior The current Netty QUIC API documentation describes as the hostname verification algorithm for authenticating the server in client contexts. The method explicitly supports "HTTPS" and states that disables hostname verification. The Java contract states that a non-null algorithm requires endpoint identification to run against the peer host presented during the TLS handshake. The public GHSA-c653-97wb-rcgb / CVE-2026-50010 advisory also establishes Netty's security intent: clients configured with a standard trust manager should not lose hostname verification when is enabled in Netty 4.2. The QUIC path violates this intent in the patched release: the engine and its peer host are available, but the callback discards them for standard instances.

Goal Reached Thanks to every supporter — we hit 100%!

Netty QUIC Client X509TrustManager Hostname Verification Bypass (CVE-2026-50010)

More from this source