CVE-2026-100665: Netty QUIC Auth Bypass Vulnerability

CVE-2026-100665 Overview

CVE-2026-100665 is a certificate validation flaw [CWE-295] in the Netty asynchronous networking framework. Netty versions from 4.2.11.Final through 4.2.17.Final contain an incomplete hostname verification fix in the QUIC certificate verification path. When a plain X509TrustManager is configured, the BoringSSLCertificateVerifyCallback discards the SSLEngine, which prevents endpoint identification from running even when HTTPS verification is explicitly configured. Attackers positioned on the network path can present a valid certificate chain for an unrelated hostname that the plain trust manager accepts, bypassing hostname authentication for QUIC clients.

Critical Impact

Network-adjacent attackers can impersonate QUIC servers to Netty-based clients by presenting any certificate chain their trust manager accepts, enabling man-in-the-middle attacks against TLS-protected sessions.

Affected Products

• Netty 4.2.11.Final through 4.2.17.Final (QUIC codec with plain X509TrustManager)
• Applications using QuicSslContextBuilder with a non-extended trust manager
• Downstream frameworks and services embedding affected Netty QUIC codec versions

Discovery Timeline

• 2026-09-26 - CVE-2026-100665 published to NVD
• 2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100665

Vulnerability Analysis

The vulnerability lives in Netty's QUIC TLS integration layer, specifically in the BoringSSL-backed certificate verification callback. QUIC relies on TLS 1.3 for session establishment, and clients must verify that the server certificate matches the intended hostname. Netty previously added an incomplete fix for hostname verification, but that fix failed to cover the case where callers supply a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager.

In the affected code path, BoringSSLCertificateVerifyCallback discards the SSLEngine reference when operating with a plain trust manager. Because endpoint identification in the JDK is driven through SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") on the engine, dropping the engine silently disables that check. The trust manager still validates the chain against the configured trust store, so an attacker only needs a certificate that chains to any trusted CA, regardless of the subject name.

Root Cause

The root cause is a type-handling gap between X509TrustManager and X509ExtendedTrustManager. Only the extended variant exposes the checkServerTrusted(chain, authType, SSLEngine) overload needed for hostname validation. The QUIC verification callback did not wrap the plain trust manager in an adapter that re-attaches engine context, so hostname checking was skipped entirely while chain validation continued to succeed.

Attack Vector

An attacker with the ability to intercept or redirect QUIC traffic, such as a rogue Wi-Fi operator, an on-path network device, or a BGP/DNS hijacker, can terminate the QUIC handshake using a certificate issued to a domain they legitimately control. If that certificate chains to a CA in the client's trust store, the Netty QUIC client accepts the session without ever confirming that the certificate's subject or SAN entries match the requested server hostname.

// Patch from io/netty/handler/codec/quic/QuicSslContextBuilder.java
// Source: https://github.com/netty/netty/commit/994e887ed9
 import javax.net.ssl.KeyManager;
 import javax.net.ssl.KeyManagerFactory;
 import javax.net.ssl.SSLEngine;
+import javax.net.ssl.SSLParameters;
 import javax.net.ssl.TrustManager;
 import javax.net.ssl.TrustManagerFactory;
 import javax.net.ssl.X509ExtendedKeyManager;

The follow-up fix in InsecureTrustManagerFactory.java wraps plain trust managers so hostname verification is no longer silently disabled. See the GitHub Security Advisory GHSA-mj35-3qqm-q387 for full patch references.

Detection Methods for CVE-2026-100665

Indicators of Compromise

• Unexpected QUIC/HTTP3 sessions terminating at hostnames or IP addresses that do not match configured upstream endpoints.
• TLS certificates presented on QUIC flows whose Subject Alternative Name does not include the dialed hostname.
• Dependency manifests (pom.xml, build.gradle) resolving io.netty:netty-codec-quic or netty-all to versions 4.2.11.Final through 4.2.17.Final.

Detection Strategies

• Perform Software Composition Analysis across build artifacts and container images to identify vulnerable Netty QUIC codec versions.
• Inspect application configuration for use of QuicSslContextBuilder with trust managers that do not extend X509ExtendedTrustManager.
• Correlate egress QUIC flows (UDP/443) against expected destinations and alert on anomalous Server Name Indication values.

Monitoring Recommendations

• Enable TLS and certificate telemetry on network sensors capable of parsing QUIC Initial packets to capture server certificate metadata.
• Log Netty SSL handshake events at the application layer and alert on handshakes completing without endpoint identification applied.
• Monitor for new QUIC peers observed from workloads that historically only connected to a fixed set of services.

How to Mitigate CVE-2026-100665

Immediate Actions Required

• Upgrade Netty to 4.2.18.Final or later across all applications, services, and container base images.
• Audit custom TrustManager implementations and migrate any plain X509TrustManager subclasses to X509ExtendedTrustManager.
• Rotate credentials or tokens that transited QUIC sessions established by vulnerable clients in untrusted network environments.

Patch Information

The fix is distributed in Netty 4.2.18.Final. Relevant commits include GitHub Netty Commit 994e887ed9, which adds SSLParameters-based hostname identification support to QuicheQuicSslEngine, and GitHub Netty Commit 09e72c4f, which prevents wrapping a plain trust manager from silently disabling hostname verification. Additional context is published in the VulnCheck Advisory for Netty.

Workarounds

• Configure QUIC clients with an X509ExtendedTrustManager so the verification callback retains the SSLEngine and performs HTTPS endpoint identification.
• Explicitly set SSLParameters.setEndpointIdentificationAlgorithm("HTTPS") and verify at runtime that the parameter survives into the TLS handshake.
• Restrict QUIC egress to known destinations via network policy until patched builds are deployed.

# Verify installed Netty QUIC codec version in a Maven project
mvn dependency:tree -Dincludes=io.netty:netty-codec-quic

# Enforce patched version via Maven dependency management
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-codec-quic</artifactId>
#   <version>4.2.18.Final</version>
# </dependency>