A flaw was found in GnuTLS

GnuTLS mishandles ownership in its Subject Alternative Name export logic when a certificate contains an otherName entry with a malformed or invalid type-id OID. The library calls asn1_delete_structure() on an ASN.1 node it does not actually own, and the parent frees the same structure again — classic CWE-415 double-free. The bug is reachable through public GnuTLS APIs whenever an application parses/exports a hostile certificate's SAN extension. Confirmed affected: GnuTLS 3.8.9 and earlier across the 3.x line; distro-patched in Ubuntu (3.8.9-2ubuntu3.1, 3.8.3-1.1ubuntu3.4, 3.7.3-4ubuntu1.7), Debian 12 (3.7.9-2+deb12u5), and RHEL backports.

Vendor MEDIUM (6.5) is roughly fair on paper but *overstated in practice*. The CVSS vector demands AC:H (high complexity — attacker must craft a malformed OID that survives ASN.1 parsing to the exact SAN export path), and impact is scoped to C:N/I:L/A:H — no confidentiality loss, limited integrity, and DoS on whoever is parsing the cert. There is no confirmed RCE primitive in the wild; every advisory reads 'may result in denial of service or memory corruption, depending on allocator behavior'. That's a crash, not a shell.

Why this verdict

• Impact is DoS, not RCE: every advisory language settles on 'denial of service or memory corruption *depending on allocator behavior*' — modern glibc tcache guards convert the double-free into a clean abort.
• Reachability is narrow: the bug lives in the SAN *export* path, not the standard validation path. Most TLS clients never invoke gnutls_x509_crt_get_subject_alt_name() on attacker-controlled certs.
• AC:H is real: attacker must craft an OID that survives outer ASN.1 parsing and lands specifically in the otherName export branch. No off-the-shelf tooling exists.
• Role multiplier: GnuTLS is not itself a high-value-role component (it's a library, not an IdP/hypervisor/CA/PAM). Even where it's loaded into higher-value processes (e.g., Exim on a mail relay, BIND on a resolver), the chain terminates at that daemon crashing and systemd restarting it — no fleet, identity, or supply-chain pivot.
• Role multiplier — worst realistic case: GnuTLS embedded in an mTLS-terminating reverse proxy that logs peer SANs. Outcome = repeated proxy crash → localized availability incident, still not fleet-scale. Floor stays at LOW/MEDIUM.
• No KEV, EPSS ~1.2%: market signal aligns with defender intuition — nobody is racing to exploit this.

Why not higher?

MEDIUM would require credible RCE weaponization or an installed base where mass DoS translates into meaningful business impact. Neither exists: no PoC, no in-the-wild campaigns, and the trigger requires the target application to actively export SANs from an attacker-controlled cert — a narrow slice of GnuTLS consumers.

Why not lower?

IGNORE is inappropriate because the bug is genuine, network-reachable in principle, and lives in ubiquitous TLS plumbing; a determined researcher may still weaponize it against a specific allocator/target. Keep it in the backlog and let normal distro-update cadence resolve it.

1. Ride the distro update train — GnuTLS is a base OS library — apply the vendor's monthly patch bundle (apt/dnf/zypper update) as part of routine maintenance. Per noisgate remediation SLA for LOW: no fixed SLA, treat as backlog hygiene, but this will fold in within the next normal patch window on any actively-maintained distro.
2. Restart long-lived GnuTLS-linked services after upgrade — Because GnuTLS is dynamically linked into daemons like Exim, rsyslog (imgtls), BIND, and cups, a package upgrade alone leaves old code resident. Use needrestart -r a (Debian/Ubuntu) or dnf needs-restarting -r (RHEL) to enumerate and restart affected services within the same maintenance window.
3. Constrain mTLS peer cert acceptance where possible — For services that accept client certificates from arbitrary parties (a real reach vector), enforce a trusted issuer whitelist so hostile SAN structures cannot be presented by unauthenticated clients.
4. Verify glibc tcache double-free protection is active — Ensure hosts are on glibc ≥ 2.29 and not running with MALLOC_CHECK_=0 or custom allocators that disable double-free detection. This turns the vuln into a safe abort instead of a corruption primitive.

Run on each target Linux host as a normal user (root not required). Invoke as ./check-cve-2025-32988.sh. It detects installed GnuTLS package version via dpkg/rpm and compares against distro-patched thresholds.

#!/usr/bin/env bash
# check-cve-2025-32988.sh
# Detect GnuTLS double-free CVE-2025-32988 exposure
# Exit: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

verdict="UNKNOWN"
detail=""

vercmp() {
  # returns 0 if $1 >= $2 (dpkg style)
  dpkg --compare-versions "$1" ge "$2"
}

if command -v dpkg-query >/dev/null 2>&1; then
  for pkg in libgnutls30 libgnutls30t64 libgnutls28 gnutls28; do
    ver=$(dpkg-query -W -f='${Version}' "$pkg" 2>/dev/null || true)
    [ -z "$ver" ] && continue
    detail="$pkg=$ver"
    # thresholds by codename
    src=$(. /etc/os-release; echo "${VERSION_ID:-}")
    case "$src" in
      25.04) fix="3.8.9-2ubuntu3.1" ;;
      24.04) fix="3.8.3-1.1ubuntu3.4" ;;
      22.04) fix="3.7.3-4ubuntu1.7" ;;
      12)    fix="3.7.9-2+deb12u5" ;;
      *)     fix="" ;;
    esac
    if [ -n "$fix" ]; then
      if vercmp "$ver" "$fix"; then verdict="PATCHED"; else verdict="VULNERABLE"; fi
    fi
    break
  done
elif command -v rpm >/dev/null 2>&1; then
  ver=$(rpm -q --qf '%{VERSION}-%{RELEASE}' gnutls 2>/dev/null | head -1)
  if [ -n "$ver" ]; then
    detail="gnutls=$ver"
    # RHEL backports: check for CVE reference in changelog
    if rpm -q --changelog gnutls 2>/dev/null | grep -q 'CVE-2025-32988'; then
      verdict="PATCHED"
    else
      verdict="VULNERABLE"
    fi
  fi
fi

echo "$verdict ($detail)"
case "$verdict" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 1 ;;
  *)          exit 2 ;;
esac

Sources

1. NVD — CVE-2025-32988
2. GitHub Advisory GHSA-fv5h-vqpf-6fqj
3. Wiz Vulnerability Database
4. SUSE Security Advisory
5. Snyk — Debian 11 gnutls28
6. Snyk — CentOS 8 gnutls
7. SentinelOne CVE writeup
8. CVEDetails entry