CVE-2026-75595: Netty Auth Bypass Vulnerability

CVE-2026-75595 Overview

CVE-2026-75595 is a mutual TLS (mTLS) authentication bypass in Netty, an asynchronous, event-driven network application framework. The flaw resides in io.netty.handler.ssl.SslClientHelloHandler#decode, which checks the wrong offset before reading the four-byte TLS handshake header. A crafted ClientHello whose handshake header spans TLS records triggers an IndexOutOfBoundsException and causes Netty to invoke select(ctx, null), selecting the default SslContext instead of the Server Name Indication (SNI) specific context. The issue affects Netty versions prior to 4.1.137.Final and 4.2.17.Final and is tracked as CWE-754: Improper Check for Unusual or Exceptional Conditions.

Critical Impact
An unauthenticated remote attacker can bypass per-SNI clientAuth=REQUIRE mutual TLS gates when the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL and no application-layer certificate verification exists.

Affected Products

Netty versions prior to 4.1.137.Final
Netty versions prior to 4.2.17.Final
Applications relying on per-SNI SslContext selection for mTLS enforcement

Discovery Timeline

2026-08-19 - CVE-2026-75595 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-75595

Vulnerability Analysis

Netty's SslClientHelloHandler inspects the incoming TLS ClientHello to extract the SNI extension and select an SNI-specific SslContext. The handler must first read the four-byte handshake header before parsing further fields. The decode routine validates the wrong buffer offset before this read, so a ClientHello whose handshake header is split across two TLS records causes an IndexOutOfBoundsException during parsing.

When the exception propagates, Netty calls select(ctx, null), which resolves to the mapping's default SslContext rather than the SNI-matched one. In deployments that treat per-SNI clientAuth=REQUIRE as the sole mutual TLS gate, this fallback silently disables client certificate verification for that connection.

Root Cause

The root cause is an off-by-context boundary check in SslClientHelloHandler#decode. The handler evaluates the offset against an intermediate cursor instead of the readable byte count remaining in the composite buffer, so cross-record handshake fragmentation is treated as malformed input rather than a request for more data.

Attack Vector

The attack is network-reachable and requires no authentication or user interaction. An attacker crafts a TLS ClientHello where the five-byte TLS record header ends after only the first one to three bytes of the handshake header, forcing the remaining handshake header bytes into a second record. On the vulnerable path, the parser throws, Netty falls back to the default SslContext, and the handshake completes without the client certificate that the SNI-specific route would have required. The attacker then reaches the protected route as an unauthenticated peer.

Because realCodeExamples were not available for the specific SslClientHelloHandler fix, refer to the upstream fix commits for exact diffs: Netty commit 1b5abc6 and Netty commit 9e05192. The consolidated advisory is published as GHSA-c4c3-7fpv-j4q5.

Detection Methods for CVE-2026-75595

Indicators of Compromise

TLS handshakes where the ClientHello handshake header (first four bytes after the record header) is fragmented across two or more TLS records from the same peer.
Successful sessions on SNI-scoped mTLS routes without a corresponding client certificate in Netty access or audit logs.
Occurrences of IndexOutOfBoundsException originating in io.netty.handler.ssl.SslClientHelloHandler during handshake processing.

Detection Strategies

Instrument the Netty pipeline to log the resolved SslContext identity and the presence of a peer certificate for every completed handshake, then alert when SNI-protected routes resolve to the default context.
Enable JVM exception telemetry for IndexOutOfBoundsException scoped to io.netty.handler.ssl packages and forward events to your SIEM.
Add packet-capture inspection or a TLS proxy rule to flag ClientHello messages whose first TLS record carries fewer than nine bytes of handshake payload.

Monitoring Recommendations

Correlate handshake exceptions with subsequent authenticated actions on the same connection to surface bypass attempts.
Track version telemetry across Java services and identify hosts still running Netty prior to 4.1.137.Final or 4.2.17.Final.
Monitor perimeter and mesh proxies for anomalous TLS record segmentation patterns targeting mTLS-protected endpoints.

How to Mitigate CVE-2026-75595

Immediate Actions Required

Upgrade Netty to 4.1.137.Final or 4.2.17.Final across all direct and transitive dependencies.
Inventory shaded and bundled Netty copies inside application archives, container images, and third-party middleware.
Reconfigure the default SslContext used by SNI mappings to clientAuth=REQUIRE so any fallback still enforces mutual TLS.

Patch Information

The issue is fixed in Netty 4.1.137.Final and 4.2.17.Final. The upstream patches are tracked in Pull Request #17213 and Pull Request #17217, with the vulnerability details published in GHSA-c4c3-7fpv-j4q5.

Workarounds

Set the default SslContext in the SNI mapping to require client authentication, eliminating the permissive fallback path.
Add application-layer certificate verification (for example, validating the presented client certificate inside the request handler) so mTLS enforcement does not rely solely on the SNI-selected context.
Terminate TLS at an upstream proxy that enforces mutual TLS uniformly and forwards only authenticated connections to Netty.

bash

# Configuration example: enforce mTLS on the default SslContext used by SniHandler
# Maven dependency pinning
mvn versions:use-dep-version -Dincludes=io.netty:netty-all -DdepVersion=4.1.137.Final -DforceVersion=true

# Gradle pinning
./gradlew dependencies --refresh-dependencies \
  -PnettyVersion=4.1.137.Final