PHP 7

Tenable plugin 158133 maps to upstream PHP 7.4.0 through 7.4.27 missing the fix in 7.4.28 for CVE-2021-21708, a CWE-416 use-after-free in the filter extension. The vulnerable path is not "any PHP request"; it is code that uses FILTER_VALIDATE_FLOAT with min_range or max_range on attacker-controlled input, where a failed validation can crash php-fpm and *potentially* corrupt memory further.

The vendor-style scoring is too hot for enterprise prioritization because reachability is app-specific, not runtime-global. A scanner sees an old PHP version and screams; reality is you still need an exposed application route, user-controlled numeric input, and the exact filter/options pattern before the bug even starts to matter, and there is no strong evidence this became a broadly weaponized internet RCE.

Why this verdict

• Specific code path required: this is not "send one HTTP request to any PHP box." The request has to land in app code using FILTER_VALIDATE_FLOAT plus min_range or max_range.
• Posture implies narrower exposure: requiring that exact validation pattern means many PHP installs flagged by the scanner are not truly reachable for this bug, which is a strong downward adjustment from a runtime-wide CRITICAL baseline.
• Crash is easy; reliable RCE is not: public material demonstrates a crash PoC cleanly, but not a mature, commonly used exploit chain that turns this into dependable remote code execution at scale.
• No KEV or strong exploitation telemetry: without CISA KEV inclusion or credible campaign reporting, there is no practical amplifier that would keep this in the top patch queue.
• Still not LOW: PHP is heavily deployed and internet-facing apps are common, so if you *do* have the bad call pattern on exposed routes, the impact can be real.

Why not higher?

Because the attack chain has compounding friction at the very first technical gate: the attacker needs more than a vulnerable PHP version, they need a reachable application endpoint that uses one specific filter/options combination. That requirement collapses the real exposed population and makes mass exploitation less plausible than the NVD vector suggests.

Why not lower?

Because this is still memory corruption in a ubiquitous runtime, and the easy failure mode is an externally triggerable service crash on exposed applications. If you run legacy PHP 7.4 apps with ad hoc input validation, you cannot dismiss it as pure scanner noise.

1. Inventory real 7.4 exposure — Separate upstream/self-built PHP from distro-backported packages before you panic. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this scoping work now so you know which hosts are truly carrying unfixed upstream code.
2. Grep for the risky call pattern — Search codebases for FILTER_VALIDATE_FLOAT combined with min_range or max_range, then map those files to internet-facing routes. There is no mitigation SLA — go straight to the 365-day remediation window for this severity, but this is the fastest way to cut false positives and identify the handful of apps that deserve earlier change review.
3. Harden PHP-FPM isolation — Run separate pools or containers per app, use least-privilege service accounts, and keep secrets out of the web root so a worker crash or even partial compromise has less follow-on value. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but pool isolation materially lowers blast radius immediately.
4. Reduce input attack surface — Where practical, replace this validation pattern with framework-native validators or strict type parsing that does not depend on the vulnerable filter path, especially in public APIs. There is no mitigation SLA — go straight to the 365-day remediation window, so fold this into normal app maintenance unless you confirm reachable call sites.
5. Suppress version leakage — Disable unnecessary X-Powered-By disclosure and other version banners so external scanners and opportunistic attackers get less free targeting data. This does not fix the bug, but it slightly raises attacker reconnaissance cost while you work through the remediation window.

Run this on the target Linux host that actually executes PHP, not from your scanner. Invoke it as sudo bash verify-cve-2021-21708.sh /var/www/html (the docroot argument is optional but recommended); it needs read access to the PHP binary, package database, and app code if you want the reachability grep.

#!/usr/bin/env bash
# verify-cve-2021-21708.sh
# Check whether this host is likely vulnerable to CVE-2021-21708 (PHP FILTER_VALIDATE_FLOAT UAF)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u
DOCROOT="${1:-}"

have_cmd() { command -v "$1" >/dev/null 2>&1; }

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

ver_ge() {
  # returns 0 if $1 >= $2
  ! ver_lt "$1" "$2"
}

php_ver=""
if have_cmd php; then
  php_ver="$(php -r 'echo PHP_MAJOR_VERSION,".",PHP_MINOR_VERSION,".",PHP_RELEASE_VERSION;' 2>/dev/null || true)"
fi

if [ -z "$php_ver" ]; then
  echo "UNKNOWN"
  exit 2
fi

# Check for Ubuntu focal backport explicitly, because package versions may look older than upstream 7.4.28.
if have_cmd dpkg-query && dpkg-query -W -f='${Status}' php7.4-common 2>/dev/null | grep -q 'install ok installed'; then
  pkg_ver="$(dpkg-query -W -f='${Version}' php7.4-common 2>/dev/null || true)"
  if [ -n "$pkg_ver" ] && have_cmd dpkg; then
    if dpkg --compare-versions "$pkg_ver" ge '7.4.3-4ubuntu2.9'; then
      echo "PATCHED"
      exit 0
    fi
  fi
fi

case "$php_ver" in
  7.4.*)
    if ver_ge "$php_ver" "7.4.28"; then
      echo "PATCHED"
      exit 0
    fi
    ;;
  8.0.*)
    if ver_ge "$php_ver" "8.0.16"; then
      echo "PATCHED"
      exit 0
    fi
    ;;
  8.1.*)
    if ver_ge "$php_ver" "8.1.3"; then
      echo "PATCHED"
      exit 0
    fi
    ;;
  *)
    # Other branches are outside this CVE's affected ranges
    echo "PATCHED"
    exit 0
    ;;
esac

# If we get here, the runtime version is in an affected upstream range.
# Distros other than Ubuntu may have backports we cannot safely infer.
if [ -n "$DOCROOT" ] && [ -d "$DOCROOT" ]; then
  tmp1="$(mktemp)"
  tmp2="$(mktemp)"
  trap 'rm -f "$tmp1" "$tmp2"' EXIT

  grep -RIl --exclude-dir=.git --exclude-dir=vendor --exclude='*.min.*' 'FILTER_VALIDATE_FLOAT' "$DOCROOT" 2>/dev/null | sort -u > "$tmp1" || true
  grep -RIl --exclude-dir=.git --exclude-dir=vendor --exclude='*.min.*' -E 'min_range|max_range' "$DOCROOT" 2>/dev/null | sort -u > "$tmp2" || true

  if [ -s "$tmp1" ] && [ -s "$tmp2" ] && comm -12 "$tmp1" "$tmp2" | grep -q .; then
    echo "VULNERABLE"
    exit 1
  fi

  # Affected runtime, but no obvious reachable code pattern found in provided docroot.
  echo "UNKNOWN"
  exit 2
fi

# Affected runtime version, but without source inspection we cannot prove reachability.
echo "UNKNOWN"
exit 2

Sources

1. Tenable Nessus Plugin 158133
2. PHP 7.4.28 release announcement
3. PHP 7 changelog entry for 7.4.28
4. NVD CVE-2021-21708
5. PHP bug #81708
6. Ubuntu USN-5303-1
7. CISA Known Exploited Vulnerabilities Catalog
8. Bitsight observation footprint for CVE-2021-21708