PHP 5

Tenable plugin 104631 fires when a remote web server banners PHP 5.6.x earlier than 5.6.32. That release fixed two security-relevant issues in this branch: CVE-2017-16642, an out-of-bounds read in date parsing (timelib_meridian) reachable when PHP parses attacker-controlled date strings, and CVE-2016-1283, a heap overflow in bundled PCRE 8.38 triggered by compiling a crafted regular expression. In plain English: one bug can leak or crash during weird date parsing, the other needs the application to treat attacker input as the *regex pattern itself*, not just as data matched by a safe developer-written regex.

The vendor label does not match reality. Tenable inherits a 9.8 vector from the worst underlying PCRE case and stamps the plugin critical, but that assumes generic unauthenticated network exploitation that most PHP apps simply do not expose. In real deployments, CVE-2017-16642 is mostly an info-leak/crash bug, and CVE-2016-1283 depends on an unusually dangerous app design pattern. That makes this a patch-worthy internet-facing hygiene issue, not a drop-everything emergency on its own.

Why this verdict

• Big downgrade for app-specific reachability Tenable starts from a 9.8 PCRE vector, but real exploitation usually requires user control of the *regex pattern itself* or a precise date-parsing sink. Most enterprise PHP apps do not expose that to unauthenticated users.
• One underlying bug is not a generic RCE CVE-2017-16642 is an out-of-bounds read with confidentiality-focused impact. That is materially weaker than the plugin's critical label implies.
• No strong threat signal No KEV listing, no campaign evidence in the cited sources, and public material is mostly repro/crash-grade. That removes the usual reasons to keep a parser bug in the high-end buckets.

Why not higher?

If this were a broadly reachable, unauthenticated parser bug with confirmed internet exploitation, the vendor baseline would hold. But the attack chain narrows hard at the first step because the application must expose an unusually dangerous parser sink. That compounding friction is exactly why this does not deserve a HIGH or CRITICAL operational label.

Why not lower?

You are still looking at an internet-facing, outdated PHP runtime with memory-safety issues. In shops with legacy apps, search features, filter builders, importers, or custom date handling can absolutely expose the vulnerable paths, and the install base of PHP is huge. That keeps it above LOW even without active exploitation evidence.

1. Inventory every PHP 5.6 endpoint — Map all hosts, vhosts, containers, and FPM pools still serving PHP 5.6.x and tag whether they are internet-facing, authenticated-only, or internal. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but you should complete inventory immediately because this plugin is usually a marker for broader legacy exposure.
2. Review code paths that compile user regex — Search for preg_* usage where the pattern can be influenced by request data, admin UI rules, search builders, or templating features. If found, add server-side allowlists or pattern generation rather than free-form regex input; do this now if migration will be delayed, even though a MEDIUM verdict has no separate mitigation SLA.
3. Constrain untrusted date parsing — Replace permissive natural-language date parsing on untrusted input with strict formats like ISO-8601 and schema validation. This blocks the easiest published trigger style for CVE-2017-16642 and reduces noisy parser edge cases while you work toward remediation.
4. Prefer distro-patched packages over raw upstream relics — If you cannot move off legacy PHP immediately, at least verify whether the host is on a vendor-supported package stream with backports rather than a hand-built upstream tarball. That does not eliminate old-branch risk, but it avoids assuming banner version equals unpatched state.
5. Monitor PHP worker crashes and parser anomalies — Ship Apache/nginx, PHP-FPM, and application logs to your SIEM and alert on repeated worker restarts, segfaults, or bursts of malformed date/regex inputs. There is no noisgate mitigation deadline for MEDIUM, but this is cheap detection coverage you can deploy while remediation is scheduled.

Run this on the target Linux host that serves PHP, not from an auditor workstation. Save it as check_php_5632.sh, then run sudo bash check_php_5632.sh or point at a specific binary with sudo bash check_php_5632.sh /usr/bin/php; root is helpful for checking package metadata and multiple install paths, but the script can often work without it.

#!/usr/bin/env bash
# check_php_5632.sh
# Purpose: detect whether a Linux host is running upstream-style PHP 5.6.x earlier than 5.6.32
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_BIN="${1:-}"
FOUND=0
VULN=0
UNKNOWN=0

declare -a CANDIDATES
if [ -n "$TARGET_BIN" ]; then
  CANDIDATES+=("$TARGET_BIN")
fi

# Common paths
for p in /usr/bin/php /usr/local/bin/php /opt/*/bin/php /usr/sbin/php-fpm /usr/sbin/php-fpm5 /usr/sbin/php-fpm5.6 /usr/sbin/php-fpm56; do
  for r in $p; do
    [ -x "$r" ] && CANDIDATES+=("$r")
  done
done

# Deduplicate while preserving order
uniq_candidates=()
for c in "${CANDIDATES[@]:-}"; do
  skip=0
  for u in "${uniq_candidates[@]:-}"; do
    [ "$c" = "$u" ] && skip=1 && break
  done
  [ $skip -eq 0 ] && uniq_candidates+=("$c")
done

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

check_php_version() {
  local bin="$1"
  local out ver
  out="$($bin -v 2>/dev/null | head -n1 || true)"
  ver="$(printf '%s' "$out" | sed -nE 's/^PHP[[:space:]]+([0-9]+\.[0-9]+\.[0-9]+).*/\1/p')"

  if [ -z "$ver" ]; then
    echo "UNKNOWN: could not parse version from $bin"
    return 2
  fi

  echo "INFO: $bin reports PHP $ver"

  case "$ver" in
    5.6.*)
      if version_lt "$ver" "5.6.32"; then
        echo "VULNERABLE: $bin is PHP $ver (< 5.6.32)"
        return 1
      else
        echo "PATCHED: $bin is PHP $ver (>= 5.6.32)"
        return 0
      fi
      ;;
    *)
      echo "PATCHED: $bin is not in the affected PHP 5.6.x range"
      return 0
      ;;
  esac
}

if [ ${#uniq_candidates[@]} -eq 0 ]; then
  echo "INFO: no PHP binaries discovered in common paths"
else
  for bin in "${uniq_candidates[@]}"; do
    FOUND=1
    check_php_version "$bin"
    rc=$?
    [ $rc -eq 1 ] && VULN=1
    [ $rc -eq 2 ] && UNKNOWN=1
  done
fi

# Package-manager hints for distro installs/backports
if command -v dpkg-query >/dev/null 2>&1; then
  echo "INFO: dpkg package hints:"
  dpkg-query -W -f='${Package} ${Version}\n' 'php*' 2>/dev/null | grep -E '^(php|libapache2-mod-php|php5|php5.6|php7|php8)' || true
elif command -v rpm >/dev/null 2>&1; then
  echo "INFO: rpm package hints:"
  rpm -qa | grep -Ei '^(php|php56|php5)' || true
fi

if [ $VULN -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
fi

if [ $FOUND -eq 0 ] && [ $UNKNOWN -eq 0 ]; then
  echo "UNKNOWN: no PHP runtime found; check containers, alternate paths, or webserver-specific modules"
  exit 2
fi

if [ $UNKNOWN -eq 1 ]; then
  echo "UNKNOWN"
  exit 2
fi

echo "PATCHED"
exit 0

Sources

1. Tenable Nessus Plugin 104631
2. PHP 5.6.32 Release Announcement
3. PHP 5 Changelog
4. NVD CVE-2016-1283
5. NVD CVE-2017-16642
6. PHP Bug #75055 for CVE-2017-16642
7. Ubuntu USN-3566-1 PHP Vulnerabilities
8. BitSight Observation Footprint for CVE-2017-16642