Netty is an asynchronous

CVE-2026-75596 affects Netty's io.netty.handler.ssl.SniHandler in all versions prior to 4.1.137.Final (4.1.x branch) and 4.2.17.Final (4.2.x branch). When a TLS client sends a fragmented ClientHello, the default SniHandler constructors call handshakeBuffer.clear() followed by writeBytes() on every incoming TLS record, re-copying *all* previously accumulated bytes each time. An unauthenticated remote attacker sends a first record advertising a large ClientHello (e.g., 4096 bytes) and then drips the body in thousands of one-byte records, producing O(n²) CPU work. With 4,095 one-byte fragments the handler internally copies 8,386,560 bytes from just 24,579 bytes on the wire — a 341× amplification ratio — starving the Netty event loop of CPU and degrading TLS handling for every other client sharing that loop.

The Netty project's own GHSA advisory (GHSA-fccg-mwvh-qqg4) scores this at CVSS 6.9 Moderate using CVSS 4.0 with VA:L. Several aggregator sites inflate it to 8.7 by flipping Availability Impact to High — that overshoot is misleading. The attack consumes CPU on event-loop threads but does not crash the JVM, does not leak data, and does not grant code execution. Recovery is automatic once malicious connections close or time out. Real-world severity hinges on whether SNI termination happens inside your Netty application or at an upstream reverse proxy: if a load balancer handles TLS before traffic reaches Netty, the vulnerable code path is never triggered. For teams where Netty *is* the TLS front door, this is a real but bounded availability risk.

1. Upgrade netty-handler to 4.1.137.Final or 4.2.17.Final — The definitive fix eliminates the quadratic re-copy in SniHandler's ClientHello aggregation. As a MEDIUM-severity finding the noisgate remediation SLA allows up to 365 days, but given the trivial exploitation mechanics, prioritize within your next quarterly dependency update cycle.
2. Terminate TLS at an upstream reverse proxy — If Nginx, HAProxy, Envoy, or a hardware load balancer terminates TLS before traffic reaches Netty, the vulnerable SniHandler path is never invoked. This is the strongest compensating control when an immediate library upgrade is infeasible. Deploy within your standard change window.
3. Enforce per-source-IP TLS handshake rate limits — Use iptables connlimit, firewall rules, or load-balancer policies to cap concurrent new TLS connections per source IP (e.g., 20/s). This bounds the number of event-loop threads an attacker can exhaust from a single vantage point without affecting legitimate traffic patterns.
4. Set aggressive TLS handshake timeouts — Configure Netty SslHandler or upstream infrastructure to enforce short TLS handshake timeouts (5-10 seconds). The fragment-drip attack needs sustained delivery of thousands of records — a tight timeout kills the connection before quadratic cost peaks.
5. Monitor event-loop thread CPU and TLS handshake latency — Instrument JVM monitoring (Micrometer, Prometheus JMX exporter) to alert on sustained high CPU in Netty I/O threads and rising p99 TLS handshake latency. This enables early detection and manual connection termination during an active attack.

Run on each target host where Java applications may embed Netty. Execute as bash check_cve_2026_75596.sh /opt/apps (substitute your application deployment root). Root access gives full filesystem coverage. The script scans for netty-handler-*.jar files and compares versions against fixed releases.

#!/usr/bin/env bash
# CVE-2026-75596 Netty SniHandler Quadratic DoS Check
# Usage: bash check_cve_2026_75596.sh [/path/to/scan]
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail
SEARCH="${1:-/}"
FOUND=0
VULN=0
echo "=== CVE-2026-75596 Netty SniHandler Check ==="
echo "Scanning: $SEARCH"
echo ""
while IFS= read -r jar; do
  FOUND=1
  name=$(basename "$jar")
  ver=$(echo "$name" | sed 's/netty-handler-//;s/\.Final//g;s/\.jar//;s/-[a-zA-Z].*$//')
  if [ -z "$ver" ]; then
    echo "[?] UNKNOWN: $jar"
    continue
  fi
  maj=$(echo "$ver" | cut -d. -f1)
  min=$(echo "$ver" | cut -d. -f2)
  pat=$(echo "$ver" | cut -d. -f3)
  if [ -z "$pat" ]; then
    echo "[?] UNKNOWN format: $jar ($ver)"
    continue
  fi
  SAFE=0
  if [ "$maj" -eq 4 ] && [ "$min" -eq 2 ] && [ "$pat" -ge 17 ]; then SAFE=1; fi
  if [ "$maj" -eq 4 ] && [ "$min" -eq 1 ] && [ "$pat" -ge 137 ]; then SAFE=1; fi
  if [ "$maj" -gt 4 ]; then SAFE=1; fi
  if [ "$maj" -eq 4 ] && [ "$min" -gt 2 ]; then SAFE=1; fi
  if [ "$SAFE" -eq 1 ]; then
    echo "[+] PATCHED: $jar (v$ver)"
  else
    echo "[!] VULNERABLE: $jar (v$ver)"
    VULN=1
  fi
done < <(find "$SEARCH" -name "netty-handler-*.jar" -type f 2>/dev/null)
echo ""
if [ "$FOUND" -eq 0 ]; then
  echo "UNKNOWN - No netty-handler JARs found under $SEARCH"
  exit 2
elif [ "$VULN" -gt 0 ]; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi

1. Netty GHSA Advisory (GHSA-fccg-mwvh-qqg4)
2. OpenCVE — CVE-2026-75596
3. Ubuntu Security — CVE-2026-75596
4. GitLab Advisory Database
5. OSV — CVE-2026-75596
6. Keycloak Downstream Issue #52548
7. Strix.ai CVE Detail
8. DailyCVE Summary