Netty is an asynchronous

CVE-2026-73508 is a resource-leak bug in Netty's netty-codec-dns module. When the DNS record decoder encounters a malformed domain name — one containing characters that violate IDNA rules or embedded null bytes — the call to IDN.toASCII() or encodeDomainName() throws an IllegalArgumentException. The exception handler fails to release the associated ByteBuf objects (either retainedDuplicate() copies in DefaultDnsRecordDecoder or freshly allocated buffers in DnsCodecUtil.decompressDomainName()). An unauthenticated remote attacker can send crafted DNS packets that trigger the leak repeatedly, incrementally exhausting direct memory. Affected versions are netty-codec-dns prior to 4.1.136.Final (4.1.x branch) and prior to 4.2.16.Final (4.2.x branch). Any application that wires up Netty's DnsNameResolver or a custom DNS server using these codecs is in scope — but applications using Netty for HTTP, gRPC, or other protocols without DNS codec are not affected.

The vendor's MEDIUM / 5.3 rating is honest and mostly accurate. The CVSS vector itself encodes the key limitation: A:L, meaning partial degradation, not a full crash. This isn't a one-packet kill — the attacker needs sustained traffic over time to accumulate enough leaked buffers to push the JVM toward OutOfMemoryError. In modern container orchestrators (Kubernetes, ECS), affected pods hit their memory limit, get OOM-killed, and restart automatically, reducing the blast radius to transient service blips rather than sustained outages. The real-world severity is a touch *below* the vendor's 5.3 once you account for the subset of Netty deployments actually loading netty-codec-dns.

1. Upgrade netty-codec-dns to 4.1.136.Final or 4.2.16.Final — The definitive fix. A dependency version bump in your Maven/Gradle build resolves the leak. Deploy within the noisgate remediation SLA of 365 days for MEDIUM severity. If you manage a BOM (Spring Boot, Quarkus, Micronaut), check whether your framework has already pulled the fix into a platform release.
2. Set explicit direct memory limits on JVMs using Netty DNS — Configure -XX:MaxDirectMemorySize to a value your monitoring can alert on (e.g., 256m–512m). This caps the blast radius of any direct-memory leak, not just this CVE. The JVM will OOM-kill faster, and container orchestration restarts the pod. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
3. Monitor JVM direct memory usage — Add alerting on jvm.direct.memory.used or Netty's PooledByteBufAllocator metrics via Micrometer/Datadog/Prometheus. A monotonic climb with no plateau is a leak indicator. This is detective, not preventive, but it ensures you catch exploitation attempts early.
4. Rate-limit DNS traffic to Netty DNS listeners — If you run a custom DNS server on Netty (rare), apply DNS query-rate limiting at the network edge or in-app. For internal DnsNameResolver usage, this is less applicable since the resolver initiates queries, not receives them — but you can restrict which upstream nameservers are queried.

Run this script on any host or CI runner with access to the application's classpath or Maven/Gradle dependency tree. It checks whether netty-codec-dns is present and whether its version is patched. No special privileges required. Example: bash check_cve_2026_73508.sh /path/to/app/lib or bash check_cve_2026_73508.sh (scans current directory recursively for JARs).

#!/usr/bin/env bash
# check_cve_2026_73508.sh — Detect CVE-2026-73508 (Netty DNS codec memory leak)
# Usage: bash check_cve_2026_73508.sh [directory_to_scan]
# Exit codes: 0 = PATCHED/not affected, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

SCAN_DIR="${1:-.}"
FOUND=0
VULNERABLE=0

echo "[*] Scanning for netty-codec-dns JARs in: $SCAN_DIR"

while IFS= read -r -d '' jar; do
  basename_jar=$(basename "$jar")
  if [[ "$basename_jar" =~ ^netty-codec-dns-([0-9]+)\.([0-9]+)\.([0-9]+)\.Final\.jar$ ]]; then
    FOUND=1
    MAJOR="${BASH_REMATCH[1]}"
    MINOR="${BASH_REMATCH[2]}"
    PATCH="${BASH_REMATCH[3]}"
    VERSION="${MAJOR}.${MINOR}.${PATCH}.Final"
    echo "[*] Found: $jar (version $VERSION)"

    # 4.1.x branch: fixed in 4.1.136.Final
    if [[ "$MAJOR" -eq 4 && "$MINOR" -eq 1 ]]; then
      if [[ "$PATCH" -ge 136 ]]; then
        echo "[+] PATCHED — $VERSION >= 4.1.136.Final"
      else
        echo "[-] VULNERABLE — $VERSION < 4.1.136.Final"
        VULNERABLE=1
      fi
    # 4.2.x branch: fixed in 4.2.16.Final
    elif [[ "$MAJOR" -eq 4 && "$MINOR" -eq 2 ]]; then
      if [[ "$PATCH" -ge 16 ]]; then
        echo "[+] PATCHED — $VERSION >= 4.2.16.Final"
      else
        echo "[-] VULNERABLE — $VERSION < 4.2.16.Final"
        VULNERABLE=1
      fi
    # Older major/minor branches (< 4.1) are likely vulnerable
    elif [[ "$MAJOR" -lt 4 || ("$MAJOR" -eq 4 && "$MINOR" -lt 1) ]]; then
      echo "[-] VULNERABLE — $VERSION is older than any patched branch"
      VULNERABLE=1
    else
      echo "[?] UNKNOWN branch $MAJOR.$MINOR — verify manually"
    fi
  fi
done < <(find "$SCAN_DIR" -type f -name 'netty-codec-dns-*.jar' -print0 2>/dev/null)

# Also check Maven/Gradle dependency output if piped
if [[ "$FOUND" -eq 0 ]]; then
  echo "[*] No netty-codec-dns JARs found in $SCAN_DIR"
  echo "[*] Tip: try 'mvn dependency:tree | grep netty-codec-dns' or 'gradle dependencies | grep netty-codec-dns'"
  echo "UNKNOWN"
  exit 2
fi

if [[ "$VULNERABLE" -eq 1 ]]; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi

1. GitHub Security Advisory — GHSA-mfg7-5gfp-c4w3
2. CVE-2026-73508 — MITRE CVE Record
3. CVE-2026-73508 — Ubuntu Security Tracker
4. Netty Official Adopters List
5. OpenCVE — CVE-2026-73508 Details
6. Maven Central — netty-codec-dns
7. OSV — CVE-2026-73508