PHP 5

Tenable plugin 107216 maps to CVE-2018-7584. The bug sits in PHP's HTTP response parsing path, specifically php_stream_url_wrap_http_ex() in ext/standard/http_fopen_wrapper.c. Affected upstream versions are PHP through 5.6.33, 7.0.x before 7.0.28, 7.1.x through 7.1.14, and 7.2.x through 7.2.2; PHP 5.6.34 is the fix point for the 5.6 branch. The trigger condition is not 'send a bad request to the web server' but 'make the vulnerable PHP runtime fetch an attacker-controlled HTTP response' via URL wrappers such as file_get_contents("http://...").

The headline CVSS/NVD view (9.8 / CRITICAL) overshoots what most enterprise defenders should prioritize. Yes, the memory-safety bug is real, and public PoC material exists, but the reachable population is much smaller than 'all internet-facing PHP'. An attacker usually needs a second bug or an application feature that lets them steer PHP into making an outbound request to an attacker-controlled server; without that, the vulnerable code path is dead. That friction downgrades this from emergency patching to targeted medium-priority cleanup, especially since public material is mainly DoS-oriented, not a field-proven reliable RCE chain.

Why this verdict

• Baseline starts too high: the NVD/Tenable-style 9.8 assumes a generic unauthenticated network bug, but this parser flaw sits behind application behavior that must first cause PHP to fetch a malicious HTTP response.
• Attacker needs a second foothold or feature: SSRF, a webhook/importer, or some user-controlled remote-fetch capability is typically required. That means many deployments are only exposed *after* a separate app weakness or risky feature is in play.
• Reachable population is smaller than 'all PHP': PHP is everywhere, but only a subset of apps let untrusted users influence outbound requests. Version prevalence is not the same as exploit-path prevalence.
• Public weaponization is weak: there is a public Exploit-DB PoC, but it is oriented around crashing the process. I did not find strong evidence of a mature, broadly used RCE exploit chain.
• Still not low: if you do have SSRF/webhook/import features on vulnerable legacy PHP, the attacker can remotely drive memory corruption in the runtime itself, which is too dangerous to shrug off as backlog dust.

Why not higher?

This is not a clean 'send one packet to the public web server and win' bug. The chain usually requires attacker control over the URL or upstream response source that PHP fetches, which implies a narrower and more application-specific path than classic edge RCE. Also, the public exploit material is not a convincing internet-scale RCE ecosystem.

Why not lower?

It is still a memory-corruption bug in the PHP runtime, not a cosmetic parser oddity. Environments with SSRF primitives, feed importers, webhooks, or permissive outbound fetch features can make the bug remotely triggerable, and vulnerable PHP 5.6 estates tend to have plenty of neighboring risk.

1. Constrain outbound fetches — Restrict app-tier egress so PHP cannot freely connect to attacker-controlled hosts. This directly breaks the exploit chain because the vulnerable code path needs an outbound HTTP response to parse. For a MEDIUM verdict there is no mitigation SLA; implement this as normal hardening while you work toward patching within the 365-day remediation window.
2. Audit SSRF and fetch features — Inventory code paths and product features that let users trigger server-side URL retrievals: webhooks, feed readers, remote image fetchers, SSO metadata imports, health checks, callback validators. Those apps should be prioritized ahead of generic brochureware sites. There is no mitigation SLA for MEDIUM here, so use this to triage where patching matters most first.
3. Disable risky URL-wrapper usage where feasible — If specific apps do not need remote URL access via convenience helpers, remove or refactor those paths and prefer tightly controlled client libraries with destination allowlists. That reduces both this CVE and the broader SSRF blast radius. Again, no mitigation SLA — treat it as targeted hardening before the remediation deadline.
4. Monitor worker crash loops — Set alerts on PHP-FPM worker restarts, segfaults, and unusual outbound calls to rare domains from app tiers. This won't prevent exploitation, but it is your best chance of spotting abuse if a fetch-capable app is targeted. For MEDIUM, fold this into standard detection engineering rather than emergency change windows.

Run this on the target Linux host that has PHP installed, not from an auditor workstation. Invoke it as sudo bash check-cve-2018-7584.sh or bash check-cve-2018-7584.sh; no root is strictly required for php -v, but package backport checks are more reliable with local package metadata available. The script outputs VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check-cve-2018-7584.sh
# Detect likely exposure to CVE-2018-7584 on Linux PHP hosts.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

out() {
  echo "$1"
  exit "$2"
}

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

ver_ge() {
  # returns true if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

ver_lt() {
  ! ver_ge "$1" "$2"
}

php_bin="${PHP_BIN:-php}"
if ! have_cmd "$php_bin"; then
  out "UNKNOWN: php binary not found" 2
fi

php_version="$($php_bin -r 'echo PHP_VERSION;' 2>/dev/null || true)"
if [ -z "$php_version" ]; then
  out "UNKNOWN: unable to read PHP_VERSION" 2
fi

php_major_minor="$($php_bin -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;' 2>/dev/null || true)"
if [ -z "$php_major_minor" ]; then
  out "UNKNOWN: unable to parse PHP major/minor" 2
fi

# Upstream fixed versions for affected branches:
# 5.6.34 / 7.0.28 / 7.1.15 / 7.2.3
case "$php_major_minor" in
  5.6)
    if ver_ge "$php_version" "5.6.34"; then
      out "PATCHED: upstream PHP version $php_version is >= 5.6.34" 0
    fi
    ;;
  7.0)
    if ver_ge "$php_version" "7.0.28"; then
      out "PATCHED: upstream PHP version $php_version is >= 7.0.28" 0
    fi
    ;;
  7.1)
    if ver_ge "$php_version" "7.1.15"; then
      out "PATCHED: upstream PHP version $php_version is >= 7.1.15" 0
    fi
    ;;
  7.2)
    if ver_ge "$php_version" "7.2.3"; then
      out "PATCHED: upstream PHP version $php_version is >= 7.2.3" 0
    fi
    ;;
  *)
    out "PATCHED: installed PHP branch $php_version is outside the known affected upstream ranges for CVE-2018-7584" 0
    ;;
esac

# Package/backport checks for common distros.
# If we positively identify a known fixed distro build, mark PATCHED.
# If package metadata shows an older branch but we cannot confirm backports, return UNKNOWN.

if have_cmd dpkg-query; then
  # Ubuntu examples from USN-3600-1
  for pkg in php5-cli php5-cgi php5-fpm libapache2-mod-php5 php7.0-cli php7.0-cgi php7.0-fpm libapache2-mod-php7.0 php7.1-cli php7.1-cgi php7.1-fpm libapache2-mod-php7.1; do
    if dpkg-query -W -f='${Status} ${Version}\n' "$pkg" 2>/dev/null | grep -q '^install ok installed '; then
      pkgver="$(dpkg-query -W -f='${Version}' "$pkg" 2>/dev/null)"
      case "$pkg" in
        php7.1-*|libapache2-mod-php7.1)
          if ver_ge "$pkgver" "7.1.15-0ubuntu0.17.10.1"; then
            out "PATCHED: package $pkg at $pkgver includes the Ubuntu fix baseline" 0
          else
            out "UNKNOWN: package $pkg at $pkgver is on an affected branch; verify distro backports or upgrade" 2
          fi
          ;;
        php7.0-*|libapache2-mod-php7.0)
          if ver_ge "$pkgver" "7.0.28-0ubuntu0.16.04.1"; then
            out "PATCHED: package $pkg at $pkgver includes the Ubuntu fix baseline" 0
          else
            out "UNKNOWN: package $pkg at $pkgver is on an affected branch; verify distro backports or upgrade" 2
          fi
          ;;
        php5-*|libapache2-mod-php5)
          # Ubuntu 14.04 php5 packages were fixed via backport even though upstream 5.5 looked older.
          if ver_ge "$pkgver" "5.5.9+dfsg-1ubuntu4.24"; then
            out "PATCHED: package $pkg at $pkgver includes the Ubuntu backport fix baseline" 0
          else
            out "UNKNOWN: package $pkg at $pkgver is old and may still be vulnerable; verify vendor backports or replace" 2
          fi
          ;;
      esac
    fi
  done
fi

if have_cmd rpm; then
  # SUSE advisories backported the fix while keeping older-looking upstream base versions.
  # We do not attempt complete distro-specific EVR logic here; if RPM-managed and branch looks affected,
  # require package/advisory confirmation.
  rpm_php_pkg="$(rpm -qa | grep -E '^(php|php7)(-|$)' | head -n1 || true)"
  if [ -n "$rpm_php_pkg" ]; then
    out "UNKNOWN: RPM-based PHP package detected ($rpm_php_pkg); check vendor advisory/backport status for CVE-2018-7584" 2
  fi
fi

# If we got here, branch is affected upstream and we found no positive backport evidence.
out "VULNERABLE: upstream PHP version $php_version is in a known affected range and no distro backport fix was confirmed" 1

Sources

1. Tenable Nessus Plugin 107216
2. NVD CVE-2018-7584
3. PHP security bug #75981
4. PHP fix commit 523f230
5. PHP 5.6.34 release announcement
6. Ubuntu USN-3600-1
7. SUSE-SU-2018:0646-1
8. Exploit-DB EDB-44846