Netty CVE-2026-100665

Requires all of: (1) a Netty QUIC client on versions 4.2.11.Final through 4.2.17.Final; (2) the application configured with a PLAIN javax.net.ssl.X509TrustManager (not an X509ExtendedTrustManager) - the BoringSSLCertificateVerifyCallback discards the SSLEngine for plain trust managers so endpoint identification never runs; (3) HTTPS/endpoint-identification hostname verification nominally enabled (the flaw silently defeats it); and (4) an active attacker on the network path able to intercept the connection and present a valid-but-wrong-hostname certificate chain the trust manager will accept. Limiting factors: exploitation is impossible without an MITM/on-path position, does not affect clients using X509ExtendedTrustManager, and is confined to the QUIC certificate-verification code path rather than Netty's general TLS handling.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) scores 8.7 and implies trivial, unauthenticated remote exploitation, but this is a TLS/QUIC hostname-verification bypass (CWE-295) that in practice REQUIRES an active man-in-the-middle position on the network path - the attacker must be able to intercept the QUIC connection and present a mis-issued/wrong-hostname certificate. That MITM prerequisite is not reflected in the vendor's AT:N and materially raises real attack complexity; I assess AC:H (3.1) / AT:P (4.0). The vendor rates VC:H but VI:N, yet a successful hostname bypass on an interactive client channel typically enables both interception (C) and traffic manipulation (I), so integrity impact is arguably understated. No EPSS score, no CISA KEV listing, and no public POC were provided - exploitation status is 'no public exploit identified at time of analysis.' Net: a genuine, patch-worthy authentication-integrity flaw, but realistic priority is MEDIUM rather than the 8.7 'high' would suggest, gated on a narrow config (plain X509TrustManager over QUIC) plus network-path access, not opportunistic mass exploitation.

A Netty-based QUIC/HTTP3 client (versions 4.2.11-4.2.17) configured with a plain X509TrustManager and HTTPS endpoint identification connects to a remote server. An attacker positioned on the network path (rogue Wi-Fi, compromised router, BGP/DNS redirection) intercepts the handshake and presents a certificate chain issued for a DIFFERENT hostname; because the SSLEngine is discarded for plain trust managers, hostname identification never runs and the client accepts it, letting the attacker impersonate the server and read/alter the session. No public exploit code is currently identified.