A 1-byte stack buffer over-read was identified in the MatchDomainName function

CVE-2026-5772 is a 1-byte stack buffer over-read in MatchDomainName() inside wolfSSL src/internal.c, triggered during wildcard hostname validation when LEFT_MOST_WILDCARD_ONLY is active. Authoritative affected range is wolfSSL up to and including 5.9.0; the fix lands in 5.9.1. To hit it, an attacker has to drive the victim into the wildcard certificate-name matching path and supply a pattern/hostname combination where * consumes the remaining hostname so the code reads one byte past the end.

The supplied MEDIUM 5.3 rating reflects the NVD CVSS v3.1 view, but in real deployments that overstates the risk. wolfSSL itself classifies it LOW under CVSS v4.0, and that matches reality better: this is a tiny over-read with crash potential only, no demonstrated code execution, and it sits behind a specific client-side certificate validation path rather than a broad unauthenticated server attack surface.

Why this verdict

• Start below the NVD baseline: the vendor/CNA scored this LOW 2.1 CVSS v4.0, and that is closer to the actual exploit chain than the NVD MEDIUM 5.3 v3.1 score.
• Attacker position requirement: this is effectively a client-side attack that usually needs a malicious TLS endpoint or MITM position, which implies a prior foothold or user/application steering.
• Narrow reachable population: only deployments that hit MatchDomainName() with wildcard hostname validation and LEFT_MOST_WILDCARD_ONLY active are exposed, which is a major downward pressure on severity.
• Impact ceiling stays low: the flaw is a 1-byte stack over-read with source-backed crash potential only; there is no demonstrated RCE, no confidentiality loss, and no integrity loss.
• Threat intel is quiet: no KEV, no campaign reporting, no public exploit tooling found, and the supplied EPSS 0.00046 is bottom-barrel.

Why not higher?

It is not higher because the attack chain is not broadly reachable from the internet in the way the NVD vector suggests. The bug also lacks a credible path to code execution or data theft; the documented outcome is a possible crash from a 1-byte over-read in a narrow validation edge case.

Why not lower?

It is not IGNORE because this is still a real memory-safety defect in a cryptographic library used across embedded and appliance ecosystems. If you run wolfSSL in a mission-critical client role, a remotely triggerable crash path through TLS validation still deserves routine remediation and inventory attention.

1. Inventory wolfSSL consumers — Identify binaries, packages, containers, firmware images, and third-party products bundling wolfSSL so you know whether you even have exposure. For a LOW verdict there is no SLA (treat as backlog hygiene), but do this during the next normal library/firmware review so hidden copies in appliances do not linger forever.
2. Constrain outbound trust paths — Prioritize destination allowlists, certificate pinning, and tightly scoped egress for applications that use wolfSSL as a client. Those controls reduce the chance a client ever talks to an attacker-controlled TLS endpoint; for LOW, apply as backlog hygiene rather than as an emergency control.
3. Prefer vendor firmware with wolfSSL 5.9.1+ — Where wolfSSL is embedded in products, the practical fix is often a vendor firmware update rather than a direct library patch. Queue those updates in the next routine maintenance cycle because LOW has no mitigation SLA and no hard remediation SLA beyond backlog hygiene.

Run this on the Linux target host or appliance shell that may have wolfSSL installed. Invoke it as bash check_wolfssl_cve_2026_5772.sh or point it at a specific library file like bash check_wolfssl_cve_2026_5772.sh /usr/lib/libwolfssl.so; root is not usually required, but helps if library paths are restricted.

#!/usr/bin/env bash
# check_wolfssl_cve_2026_5772.sh
# Detect likely exposure to CVE-2026-5772 on Linux targets.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET_PATH="${1:-}"
FIXED_VERSION="5.9.1"
FOUND_VERSION=""
SOURCE=""

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

normalize_version() {
  echo "$1" | sed -E 's/^v//; s/[^0-9.].*$//'
}

try_pkg_config() {
  if command -v pkg-config >/dev/null 2>&1 && pkg-config --exists wolfssl 2>/dev/null; then
    pkg-config --modversion wolfssl 2>/dev/null | head -n1
    return 0
  fi
  return 1
}

try_dpkg() {
  if command -v dpkg-query >/dev/null 2>&1; then
    dpkg-query -W -f='${Version}\n' libwolfssl* wolfssl 2>/dev/null | grep -E '[0-9]' | head -n1
    return 0
  fi
  return 1
}

try_rpm() {
  if command -v rpm >/dev/null 2>&1; then
    rpm -qa | grep -Ei '^wolfssl(-libs)?-' | sed -E 's/^.*-([0-9][A-Za-z0-9.+:~_-]*)$/\1/' | head -n1
    return 0
  fi
  return 1
}

try_apk() {
  if command -v apk >/dev/null 2>&1; then
    apk info -e wolfssl >/dev/null 2>&1 && apk info -v wolfssl 2>/dev/null | head -n1 | sed -E 's/^wolfssl-//'
    return 0
  fi
  return 1
}

try_opkg() {
  if command -v opkg >/dev/null 2>&1; then
    opkg list-installed 2>/dev/null | awk '/^libwolfssl|^wolfssl/ {print $3; exit}'
    return 0
  fi
  return 1
}

try_strings_on_file() {
  local f="$1"
  [ -r "$f" ] || return 1
  strings "$f" 2>/dev/null | grep -Eo 'wolfSSL[^0-9]*v?[0-9]+\.[0-9]+\.[0-9]+' | head -n1 | grep -Eo 'v?[0-9]+\.[0-9]+\.[0-9]+'
}

if [ -n "$TARGET_PATH" ]; then
  FOUND_VERSION="$(try_strings_on_file "$TARGET_PATH")"
  FOUND_VERSION="$(normalize_version "$FOUND_VERSION")"
  if [ -n "$FOUND_VERSION" ]; then
    SOURCE="strings:$TARGET_PATH"
  fi
fi

if [ -z "$FOUND_VERSION" ]; then
  v="$(try_pkg_config || true)"
  v="$(normalize_version "$v")"
  if [ -n "$v" ]; then FOUND_VERSION="$v"; SOURCE="pkg-config"; fi
fi

if [ -z "$FOUND_VERSION" ]; then
  v="$(try_dpkg || true)"
  v="$(normalize_version "$v")"
  if [ -n "$v" ]; then FOUND_VERSION="$v"; SOURCE="dpkg"; fi
fi

if [ -z "$FOUND_VERSION" ]; then
  v="$(try_rpm || true)"
  v="$(normalize_version "$v")"
  if [ -n "$v" ]; then FOUND_VERSION="$v"; SOURCE="rpm"; fi
fi

if [ -z "$FOUND_VERSION" ]; then
  v="$(try_apk || true)"
  v="$(normalize_version "$v")"
  if [ -n "$v" ]; then FOUND_VERSION="$v"; SOURCE="apk"; fi
fi

if [ -z "$FOUND_VERSION" ]; then
  v="$(try_opkg || true)"
  v="$(normalize_version "$v")"
  if [ -n "$v" ]; then FOUND_VERSION="$v"; SOURCE="opkg"; fi
fi

if [ -z "$FOUND_VERSION" ]; then
  for f in /usr/lib*/libwolfssl.so* /usr/local/lib*/libwolfssl.so* /lib*/libwolfssl.so*; do
    [ -e "$f" ] || continue
    v="$(try_strings_on_file "$f")"
    v="$(normalize_version "$v")"
    if [ -n "$v" ]; then
      FOUND_VERSION="$v"
      SOURCE="strings:$f"
      break
    fi
  done
fi

if [ -z "$FOUND_VERSION" ]; then
  echo "UNKNOWN - wolfSSL version could not be determined from package manager metadata or library strings"
  exit 2
fi

if ver_lt "$FOUND_VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE - wolfSSL $FOUND_VERSION detected via $SOURCE; CVE-2026-5772 affects versions before $FIXED_VERSION"
  exit 1
else
  echo "PATCHED - wolfSSL $FOUND_VERSION detected via $SOURCE; fixed version threshold is $FIXED_VERSION"
  exit 0
fi

Sources

1. NVD CVE-2026-5772
2. wolfSSL security vulnerabilities page
3. wolfSSL 5.9.1 release blog
4. wolfSSL fix PR #10119
5. oss-security announcement for wolfSSL 5.9.1 CVEs
6. Debian CVE tracker entry
7. Debian source package status for wolfssl
8. CISA Known Exploited Vulnerabilities Catalog