CVE-2026-75595 in Netty
Summary
by MITRE • 08/20/2026
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Fina and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
Netty serves as a foundational asynchronous event-driven network application framework widely utilized for building high-performance client and server applications across various industries, including financial services, telecommunications, and cloud infrastructure. The vulnerability described herein resides within the Secure Sockets Layer (SSL) handler component, specifically in the io.netty.handler.ssl.SslClientHelloHandler class which is responsible for parsing incoming TLS ClientHello messages during the initial handshake phase. This handler plays a critical role in Server Name Indication processing by extracting hostname information to select the appropriate SSL context before full authentication occurs. In versions prior to 4.1.137.Final and 4.2.17.Final, a logic error exists within the decode method where an incorrect offset calculation is performed when reading the four-byte TLS handshake header. This miscalculation leads to an IndexOutOfBoundsException under specific conditions where the ClientHello message spans multiple network records or packets due to fragmentation or large payload sizes.
The operational impact of this flaw extends beyond a simple denial-of-service condition caused by the exception. When the IndexOutOfBoundsException is triggered, Netty invokes select with null parameters rather than properly parsing the SNI extension within the ClientHello. This causes the framework to fall back to selecting the default SSL context instead of the specific context associated with the requested server name. In typical deployments utilizing mutual TLS for secure access control, different virtual hosts or services are configured with distinct SSL contexts that enforce varying levels of client authentication requirements based on the SNI value. The default SSL context is often configured with a lower security posture, such as setting clientAuth to NONE or OPTIONAL, whereas the specific per-SNI contexts may be strictly configured with clientAuth set to REQUIRE to ensure mutual TLS compliance.
This discrepancy creates a significant security bypass scenario for unauthenticated remote attackers. By crafting malicious ClientHello messages that trigger the offset error and subsequent fallback behavior, an attacker can force the server to use the default SSL context even when connecting to endpoints protected by strict mutual TLS policies. Since the application layer may not perform additional certificate verification independent of Netty's handshake process, the attacker successfully bypasses the authentication gate entirely. This allows unauthorized access to sensitive resources that were intended to be restricted to authenticated clients only, effectively neutralizing a primary defense mechanism in zero-trust architectures or secure API gateway deployments.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it stems from incorrect parsing and boundary checking of incoming network data. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity because the system fails to correctly identify the intended security context before proceeding with the handshake. In terms of attack vectors, this falls under MITRE ATT&CK technique T1078 Valid Accounts or more broadly T1190 Exploit Public-Facing Application as it allows an unauthenticated actor to bypass authentication controls on a network-facing service. The exploitation requires no prior access and can be conducted remotely over standard TLS ports such as 443, making it particularly dangerous in public-facing environments where SNI is actively used for virtual hosting or routing.
Mitigation strategies primarily involve upgrading the Netty dependency to version 4.1.137.Final or later, which corrects the offset calculation logic and ensures that the SSL context selection process remains robust even when handling fragmented TLS records. Organizations relying on mutual TLS should also implement defense-in-depth measures by ensuring that application-layer code performs independent certificate validation regardless of the underlying transport layer configuration. This includes verifying client certificates against a trusted Certificate Authority list at the application level, thereby providing a secondary check that would catch any bypass attempts resulting from framework-level vulnerabilities or misconfigurations. Regular auditing of dependency versions and automated vulnerability scanning tools should be employed to detect outdated Netty libraries in production environments promptly.