PHP 5

Tenable plugin 121602 fires when a remote banner shows PHP 5.6.x earlier than 5.6.40. The bundle covers six different flaws fixed in the 5.6.40 security release, including memory-safety bugs in gd, xmlrpc, PHAR, and mbstring/oniguruma. Affected upstream range for this finding is straightforward: PHP 5.6.0 through 5.6.39.

The vendor scoring is too hot for most enterprise reality. Tenable currently labels the plugin Critical because it inherits a 9.8 vector from CVE-2019-9023, but the actual attack surface is fragmented: an attacker generally needs a reachable vulnerable code path in a specific extension and attacker-controlled malformed input, not just a socket to a PHP web server. That is still bad on public legacy web stacks, but it is not the same thing as a broadly reliable pre-auth RCE like a modern edge appliance bug.

Why this verdict

• Start at 9.8, then subtract reachability debt: the vendor score inherits worst-case CVE-2019-9023, but an attacker still needs a live vulnerable parser path, not just network access to a PHP host.
• Extension and app prerequisites matter: xmlrpc, PHAR, mbstring, and gd are not equally exposed across real estates; each missing extension or unreachable function is compounding downward pressure.
• No strong exploitation amplifier: I found no KEV listing and no compelling evidence of broad in-the-wild campaigns for this exact bundle, which keeps it out of Critical even though the branch is old and public-facing.

Why not higher?

Because this is not a turnkey edge exploit with a universal request pattern. The highest score in the bundle assumes best-case attacker reachability and worst-case impact, but the actual attack path usually requires a specific feature, a specific input sink, and often fragile memory-corruption behavior.

Why not lower?

Because the population is still externally exposed and the branch is legacy. If you do have public PHP 5.6.39 or older serving real traffic, the odds are non-trivial that at least one app path accepts attacker-controlled data into a risky extension, and the consequence sits on an internet-facing web tier.

1. Constrain exposure — Put affected sites behind a reverse proxy, VPN, allowlist, or authenticated gateway wherever business permits. For a HIGH verdict, deploy this exposure reduction within 30 days if patching is not immediate, because the main risk amplifier here is internet reachability.
2. Disable unused PHP extensions — Turn off xmlrpc, unnecessary image-processing modules, and any unused archive or multibyte features on affected pools where the application does not need them. This directly removes the vulnerable code paths and should be completed within 30 days on systems that must temporarily remain on the old branch.
3. Tighten untrusted input handling — Block or heavily validate hostile uploads, malformed XML-RPC payloads, and unexpected multibyte regex input at the application and reverse-proxy layers. This is a compensating reduction, not a fix, and it belongs within 30 days for internet-facing workloads.
4. Isolate PHP workers — Run affected pools with least-privilege service accounts, separate FPM pools per app, and filesystem/network segmentation so a parser fault cannot pivot cleanly. That containment work should land within 30 days where legacy PHP cannot yet be retired.

Run this on the target Linux host that serves the PHP application, not from your auditor workstation. Invoke it as bash verify_php_121602.sh /usr/bin/php; it needs only local shell access and no root, though package-path access and accurate php binary selection matter if multiple versions are installed.

#!/usr/bin/env bash
# verify_php_121602.sh
# Check for Tenable plugin 121602 condition: PHP 5.6.x < 5.6.40
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PHP_BIN="${1:-php}"

if ! command -v "$PHP_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN - PHP binary not found: $PHP_BIN"
  exit 2
fi

RAW_VER="$($PHP_BIN -r 'echo PHP_VERSION;' 2>/dev/null)"
if [ -z "$RAW_VER" ]; then
  echo "UNKNOWN - unable to read PHP_VERSION from $PHP_BIN"
  exit 2
fi

# Normalize to first x.y.z occurrence
VER="$(printf '%s' "$RAW_VER" | grep -Eo '^[0-9]+\.[0-9]+\.[0-9]+' || true)"
if [ -z "$VER" ]; then
  echo "UNKNOWN - unparsable PHP version: $RAW_VER"
  exit 2
fi

# version_ge A B => true if A >= B
version_ge() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

MAJOR="${VER%%.*}"
REST="${VER#*.}"
MINOR="${REST%%.*}"
PATCH="${VER##*.}"

# Primary logic for this exact Tenable finding
if [ "$MAJOR" = "5" ] && [ "$MINOR" = "6" ]; then
  if version_ge "$VER" "5.6.40"; then
    echo "PATCHED - PHP version $VER is not affected by plugin 121602's upstream rule (5.6.x < 5.6.40)"
    exit 0
  else
    echo "VULNERABLE - PHP version $VER matches plugin 121602 condition (5.6.x < 5.6.40)"
    exit 1
  fi
fi

# If version is newer than 5.6.x, this specific plugin rule does not apply.
if version_ge "$VER" "5.6.40"; then
  echo "PATCHED - PHP version $VER is outside plugin 121602's affected upstream range"
  exit 0
fi

# Older non-5.6 branches are ambiguous for this exact plugin signature.
echo "UNKNOWN - PHP version $VER does not match the exact 5.6.x rule; verify distro backports and branch-specific advisories separately"
exit 2

Sources

1. Tenable Nessus Plugin 121602
2. PHP 5.6.40 Release Announcement
3. PHP 5 ChangeLog - Version 5.6.40
4. NVD - CVE-2019-9023
5. Tenable CVE Page - CVE-2019-9021
6. Ubuntu CVE Tracker - CVE-2019-9023
7. CVE Details - CVE-2019-9021
8. Bitsight Groma - PHP 5.6.39 Observation Footprint