Advisory · CVE-2026-100665
Netty QUIC skips hostname verification with plain trust managers
Netty 4.2.11.Final through 4.2.17.Final contains an incomplete hostname-verification fix in the QUIC certificate verification path when using a plain X509TrustManager: the BoringSSL verify callback discards the SSLEngine, so endpoint identification never runs even when HTTPS verification is configured. A network-path attacker can present a certificate for the wrong hostname that the trust manager accepts. Fixed in 4.2.18.Final.
- Vendor
- Netty
- Product
- Netty
- Identifier / CWE
- CVE-2026-100665
CWE-295 - Action timing
- Immediate
Explain it like I’m five
The ID checker was told to compare the name on the badge to the name on the door. For one type of badge, the checker throws the door name away first and then approves whatever name is left, so an impostor's badge passes.
- 01QUIC handshake
A client connects over QUIC using a plain X509TrustManager with HTTPS endpoint verification configured.
- 02Discarded engine
The BoringSSL verify callback discards the SSLEngine, so the hostname it carried is never used.
- 03No identification
Endpoint identification never runs; only trust-manager acceptance is checked.
- 04Wrong-host certificate
A network-path attacker presents a valid-but-wrong-hostname certificate that is accepted.
What happened
Netty 4.2.11.Final through 4.2.17.Final contains an incomplete hostname-verification fix in the QUIC certificate verification path (CVE-2026-100665, CVSS 8.7). When using a plain X509TrustManager, the BoringSSL verify callback discards the SSLEngine, so endpoint identification never runs even when HTTPS verification is configured. A network-path attacker can present a certificate for the wrong hostname that the trust manager accepts, enabling man-in-the-middle interception of QUIC traffic. The issue is fixed in Netty 4.2.18.Final.
What to do
- Upgrade Netty to 4.2.18.Final.
- Audit QUIC client configurations: if you relied on HTTPS endpoint identification with a plain X509TrustManager, it was not actually running.
- Verify after upgrading that hostname verification is active, using a wrong-host certificate test in a non-production environment.
Management note
This is the worst kind of TLS bug: the configuration looks correct, the code path runs, but the actual check silently never happens. It is a good reminder that TLS settings deserve a live negative test, not just a config review.