Netty is an asynchronous

CVE-2026-75595 is an authentication bypass in Netty's SslClientHelloHandler#decode. An off-by-five-byte bounds-check error means the code validates 4 bytes of buffer space but then reads 9 (5-byte TLS record header + 4-byte handshake header). When an attacker sends a crafted ClientHello whose handshake header spans TLS records — with a first-record payload of only 1–3 bytes — the read triggers an IndexOutOfBoundsException. The exception handler calls select(ctx, null), which silently routes the connection to the default SslContext instead of the SNI-specific one. In deployments where the SNI-specific context enforces clientAuth=REQUIRE but the default context uses clientAuth=NONE or OPTIONAL, this converts a parsing error into a full mTLS bypass. Affected versions: all Netty prior to 4.1.137.Final and 4.2.0.Final through 4.2.16.Final.

Third-party scanners auto-labeled this CRITICAL at CVSS 9.1, but the GitHub advisory from the Netty project itself rates it High. The Netty project's rating is closer to reality. The CVSS vector uses AC:L (low attack complexity), which is misleading — the chain only fires when three simultaneous configuration conditions are met: SNI-based mTLS routing is in use, the default SslContext is more permissive than the SNI-specific one, and there is no application-layer certificate verification. Most Netty deployments use a single SslContext and never touch SslClientHelloHandler at all. Adjusting for real-world attack complexity (AC:H) yields CVSS 7.4, which better reflects the conditional nature of this bug.

1. Set the default SslContext to clientAuth=REQUIRE — The root cause of the bypass is falling back to a permissive default. If the default context also requires client certificates, the fallback is harmless. This is a one-line configuration change and the single most effective mitigation. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity.
2. Add application-layer certificate verification — In your Netty ChannelHandler pipeline, verify the peer certificate's CN/SAN against an allowlist after the TLS handshake completes. This defense-in-depth measure ensures mTLS enforcement doesn't depend solely on SslContext selection. Libraries like Bouncy Castle or standard javax.net.ssl.SSLSession#getPeerCertificates() make this straightforward.
3. Deploy TLS-aware IDS rules for anomalous ClientHello records — Write Suricata/Zeek rules to alert on TLS records with handshake payloads under 4 bytes. This is anomalous per RFC 8446 and would detect exploitation attempts. Example: alert tls any any -> any any (msg:"Suspicious tiny TLS record payload"; flow:to_server; content:|16 03|; depth:2; dsize:<9;).
4. Upgrade netty-handler to 4.1.137.Final or 4.2.17.Final — The definitive fix. Ensure both direct and transitive dependencies are updated — check your Maven/Gradle BOM. Target within 180 days per the noisgate remediation SLA for HIGH severity. Run mvn dependency:tree -Dincludes=io.netty:netty-handler to find all transitive pulls.
5. Enforce mTLS at the service mesh sidecar layer — If running Istio/Linkerd/Consul Connect, ensure sidecar-level mTLS is enforced independently of the application's Netty configuration. This provides a second authentication gate that the Netty bypass cannot circumvent.

Run this script on each application host where a Java service uses Netty. It scans for netty-handler JAR files in common deployment paths and checks their version. Requires read access to the filesystem (no root needed). Invoke: bash check_cve_2026_75595.sh /opt/myapp/lib (pass the directory containing your application's JARs).

#!/usr/bin/env bash
# check_cve_2026_75595.sh — Detect CVE-2026-75595 (Netty SslClientHelloHandler mTLS bypass)
# Usage: bash check_cve_2026_75595.sh [search_directory]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

SEARCH_DIR="${1:-/}"
VULNERABLE=0
PATCHED=0
FOUND=0

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

echo "[*] Scanning for netty-handler JARs in ${SEARCH_DIR}..."

while IFS= read -r jar; do
  FOUND=$((FOUND + 1))
  # Extract version from filename: netty-handler-4.1.136.Final.jar
  version=$(echo "$jar" | grep -oP 'netty-handler-\K[0-9]+\.[0-9]+\.[0-9]+')
  if [ -z "$version" ]; then
    # Try reading from META-INF/MANIFEST.MF inside the JAR
    version=$(unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null | grep -i 'Bundle-Version\|Implementation-Version' | head -1 | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' || true)
  fi
  if [ -z "$version" ]; then
    echo "[?] UNKNOWN version: $jar"
    continue
  fi

  major_minor=$(echo "$version" | cut -d. -f1,2)
  if [ "$major_minor" = "4.2" ]; then
    if version_gte "$version" "4.2.17"; then
      echo "[+] PATCHED ($version): $jar"
      PATCHED=$((PATCHED + 1))
    else
      echo "[-] VULNERABLE ($version < 4.2.17): $jar"
      VULNERABLE=$((VULNERABLE + 1))
    fi
  elif [ "$major_minor" = "4.1" ]; then
    if version_gte "$version" "4.1.137"; then
      echo "[+] PATCHED ($version): $jar"
      PATCHED=$((PATCHED + 1))
    else
      echo "[-] VULNERABLE ($version < 4.1.137): $jar"
      VULNERABLE=$((VULNERABLE + 1))
    fi
  else
    # Versions before 4.1 are also vulnerable
    echo "[-] VULNERABLE ($version): $jar"
    VULNERABLE=$((VULNERABLE + 1))
  fi
done < <(find "$SEARCH_DIR" -name 'netty-handler-*.jar' -type f 2>/dev/null)

echo ""
echo "=== RESULTS ==="
echo "JARs found: $FOUND | Vulnerable: $VULNERABLE | Patched: $PATCHED"

if [ "$FOUND" -eq 0 ]; then
  echo "UNKNOWN — no netty-handler JARs found in $SEARCH_DIR"
  exit 2
elif [ "$VULNERABLE" -gt 0 ]; then
  echo "VULNERABLE — CVE-2026-75595 affects $VULNERABLE JAR(s)"
  exit 1
else
  echo "PATCHED — all netty-handler JARs are at fixed versions"
  exit 0
fi

1. GitHub Security Advisory (GHSA-c4c3-7fpv-j4q5)
2. OX Security Technical Analysis
3. GitLab Advisory Database
4. Snyk Vulnerability Database
5. NVD Entry
6. SentinelOne Vulnerability Database
7. Strix CVE Detail