← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:109576 · Disclosed 2018-04-26

PHP 5

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is four different weak locks on a side door, not a blown front gate

Tenable plugin 109576 flags PHP 5.6.x < 5.6.36 and rolls up four CVEs fixed on 2018-04-26: CVE-2018-10546 (iconv infinite-loop DoS), CVE-2018-10548 (LDAP NULL dereference / crash), CVE-2018-10547 (PHAR reflected XSS on 403/404 pages), and CVE-2018-10549 (EXIF out-of-bounds read while parsing crafted JPEG metadata). Upstream fix is 5.6.36; distro backports also exist, including Debian Jessie 5.6.36+dfsg-0+deb8u1.

The scanner's headline severity overstates operational risk. The highest-score CVSS vector comes from the EXIF bug, but in real deployments an attacker still needs an application to feed attacker-controlled content into a vulnerable PHP code path like exif_read_data() or the convert.iconv stream filter; the LDAP bug needs a malicious backend server, and the PHAR issue needs user interaction. That is very different from a one-request unauthenticated server takeover.

"Old PHP, yes. Emergency patch, no: this bundle is mostly narrow DoS/XSS/file-parse risk, not a clean internet RCE."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a PHP host by banner

The attacker uses curl, nmap, or internet indexing data to identify a web service disclosing a PHP 5.6 banner. Tenable 109576 does the same thing remotely: it trusts the observed version string and does not prove the vulnerable function path is reachable.
Conditions required:
  • PHP version is exposed via HTTP headers, CGI output, or other banner data
  • The host is reachable from the attacker position
Where this breaks in practice:
  • Many enterprise hosts sit behind reverse proxies and do not expose PHP banners at all
  • Banner strings are noisy on distro-packaged PHP because backported fixes can leave older-looking version identifiers
  • Modern WAF/CDN layers often terminate the public request path before a raw PHP banner is visible
Detection/coverage: Good remote coverage for version disclosure; weak coverage for real exploitability because this is a banner-based plugin, not a local package or code-path validation.
STEP 02

Reach a vulnerable application sink

The attacker now needs an application feature that actually exercises one of the four vulnerable areas. Practical options are narrow: a file upload or image-processing workflow that calls exif_read_data(), a code path using the convert.iconv stream filter on attacker-controlled bytes, an app that talks to a malicious LDAP server, or a PHAR error page that reflects request data.
Conditions required:
  • The application must call the specific vulnerable PHP extension or function
  • Attacker-controlled data must reach that function
  • Relevant extensions (exif, iconv, ldap, phar) must be present and used
Where this breaks in practice:
  • Most PHP sites do not expose all of these sinks
  • LDAP crash path implies a trust relationship to an attacker-controlled LDAP endpoint, which is uncommon on public internet apps
  • PHAR XSS requires a user to load a crafted URL and hit a PHAR 403/404 path
Detection/coverage: SAST/DAST may find the app sink; generic network vulnerability scanners usually will not.
STEP 03

Trigger parser failure or browser-side script execution

With Burp Suite or a custom script, the attacker submits the crafted JPEG, multibyte sequence, or PHAR request. The likely outcomes are CPU spin, process crash, limited memory disclosure from an out-of-bounds read, or reflected XSS in a victim browser; the primary sources reviewed do not show a mainstream, reliable server-side RCE chain for this bundle.
Conditions required:
  • Malformed input must survive application validation
  • The vulnerable parser must process the payload
  • For XSS, a victim user must render the malicious response
Where this breaks in practice:
  • Image validation, content transformation, and upstream libraries can break crafted EXIF payloads
  • DoS conditions may only kill a worker, not the full service
  • Out-of-bounds read is materially less useful to attackers than an out-of-bounds write or deserialization RCE
Detection/coverage: App logs may show malformed uploads or repeated error paths; EDR can catch worker crashes or CPU abuse, but not the root version weakness.
STEP 04

Convert bug into business impact

If exploitation succeeds, impact is usually bounded to service instability, browser compromise through reflected XSS, or narrow information exposure. That matters on internet-facing web tiers, but the blast radius is still lower than a clean unauthenticated RCE because each branch depends on a different app-specific prerequisite.
Conditions required:
  • The target application must expose the affected workflow to untrusted users
  • Operational protections must fail to contain the result
Where this breaks in practice:
  • Pool isolation, worker recycling, and upstream request filtering often limit the damage to one feature or one worker
  • No CISA KEV listing or primary-source evidence of widespread exploitation raises the bar for emergency treatment
Detection/coverage: Runtime monitoring, PHP-FPM crash logs, WAF telemetry, and browser security reporting can show symptoms; they do not remove the underlying version debt.
03 · Intelligence Metadata

The supporting signals.

Actual scanner baselineTenable plugin 109576 is High, with CVSS v3 8.8 and VPR 5.9; the user's MEDIUM (?) note matches the plugin's *VPR/risk factor*, not its headline severity.
In-the-wild statusI found no CISA KEV listing for CVE-2018-10546/47/48/49, and Tenable states no known exploits are available for the plugin. That pushes this down from emergency status.
Proof-of-concept availabilityPublic reproduction is plausible from the upstream bug reports and CVE writeups, especially for the PHAR reflected XSS, but I did not find a primary-source Metasploit-grade RCE chain tied to this bundle.
EPSSA current Shodan CVEDB snapshot shows CVE-2018-10546 at roughly 0.649 EPSS / 98.5th percentile. Treat that as *threat likelihood for one DoS CVE*, not proof that this whole plugin is high-impact.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities catalog as checked against the public catalog URL.
CVSS vector and interpretationThe plugin inherits CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H from CVE-2018-10549. In practice that vector is aggressive for an EXIF out-of-bounds read because exploitation still depends on an app handing attacker content to the parser.
Affected versionsUpstream affected ranges are PHP < 5.6.36, 7.0.x < 7.0.30, 7.1.x < 7.1.17, and 7.2.x < 7.2.5. This Tenable plugin specifically keys on banner-detected 5.6.x < 5.6.36.
Fixed versions and backportsUpstream fixed at 5.6.36. Debian Jessie fixed php5 in 5.6.36+dfsg-0+deb8u1; Ubuntu fixed sibling branches such as php7.0 7.0.30-0ubuntu0.16.04.1 and php7.2 7.2.5-0ubuntu0.18.04.1.
Scanning and exposure realityExposure is easy to overcount: internet scanners see banners, but PHP version strings on packaged systems are notoriously noisy because vendors backport patches. For fleet triage, prefer local package evidence over remote banner evidence.
Disclosure and reporter contextUpstream shipped the fixes on 2018-04-26; NVD published the CVEs on 2018-04-29. The issues trace to PHP upstream bug IDs #76129, #76130, #76248, and #76249 rather than a single coordinated named exploit campaign.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.2/10)

The decisive factor is prerequisite stacking: every meaningful attack path requires an application-specific sink beyond 'server runs old PHP'. This is not a clean unauthenticated web-tier RCE; it is a bundle of narrower parser, DoS, and reflected XSS issues whose exploitability varies sharply by workload.

HIGH Downgrade from scanner headline severity
MEDIUM Real-world exploitability without local application context

Why this verdict

  • Down from 8.8 because the lead CVE is not a turnkey takeover: the score is anchored to CVE-2018-10549, an EXIF out-of-bounds read, but real exploitation still needs an app to parse attacker-supplied image metadata with exif_read_data().
  • More downward pressure from attacker position and app reachability: CVE-2018-10548 effectively needs a malicious LDAP backend, CVE-2018-10546 needs a specific iconv stream-filter code path, and CVE-2018-10547 needs user interaction on a .phar error page.
  • Remote population is narrower than the plugin suggests: Tenable 109576 is a remote banner check, so reverse proxies, backported distro packages, and suppressed headers all distort the true vulnerable set.

Why not higher?

There is no strong evidence here of a one-shot unauthenticated RCE, no CISA KEV listing, and Tenable explicitly says no known exploits are available. If you manage 10,000 hosts, this should not outrank genuinely weaponized web-edge bugs.

Why not lower?

This is still internet-adjacent application code on a legacy PHP branch, and image-processing plus file-upload workflows are common. If a public-facing site really does exercise EXIF or iconv on untrusted input, the bug becomes materially more interesting than background hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Validate locally before escalating — Run a local package/version check on flagged hosts first, because this plugin is banner-driven and false positives from distro backports are common. For a MEDIUM verdict there is no mitigation SLA; do this during normal validation and use the result to cut the queue.
  2. Constrain risky parsing paths — If the host is truly on vulnerable PHP, review whether apps process untrusted JPEG metadata with exif_read_data(), use convert.iconv on attacker-controlled streams, or expose .phar request paths. For MEDIUM, there is no mitigation SLA; fold this into the same application-hardening workstream used for normal change windows.
  3. Limit PHP extension surface — Disable unused extensions like ldap or exif in pools that do not need them, and remove unnecessary PHAR handling from public request paths. This reduces reachable sinks without waiting for a full application rewrite; for MEDIUM there is no mitigation SLA.
  4. Prefer supported runtimes over point fixes — If you confirm vulnerable 5.6.x, do not stop at proving 5.6.36; move the service onto a still-supported PHP branch in the normal remediation program. For MEDIUM, there is no mitigation SLA; use the remediation window to retire the legacy runtime cleanly.
What doesn't work
  • A generic WAF does not reliably stop backend EXIF, iconv, or LDAP parser flaws once the application accepts and processes the content.
  • Hiding or rewriting the PHP banner may silence the scanner, but it does not change the code actually executing on the host.
  • AV/EDR alone is not a compensating control for parser bugs and reflected XSS; it may catch crashes or follow-on activity, not prevent the vulnerable code path.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host after logging in with shell access; root is helpful for package queries but not strictly required if php is in PATH. Invoke it as bash verify-php-109576.sh or bash verify-php-109576.sh /opt/cpanel/ea-php56/root/usr/bin/php; it checks the local binary first, then known Debian/package backports, and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# verify-php-109576.sh
# Checks whether a Linux host is still vulnerable to Tenable plugin 109576
# (PHP 5.6.x < 5.6.36 multiple vulnerabilities) using local evidence.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PHP_BIN="${1:-php}"

say() { printf "%s\n" "$1"; }

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

ver_lt() {
  # Returns 0 if $1 < $2 using dpkg if present, else sort -V fallback
  if have_cmd dpkg; then
    dpkg --compare-versions "$1" lt "$2"
    return $?
  fi
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

ver_ge() {
  if have_cmd dpkg; then
    dpkg --compare-versions "$1" ge "$2"
    return $?
  fi
  ! ver_lt "$1" "$2"
}

check_dpkg_backports() {
  if ! have_cmd dpkg-query; then
    return 1
  fi

  # Debian Jessie php5 backport fix level from DLA-1397-1
  if dpkg-query -W -f='${Version}' php5 2>/dev/null | grep -q .; then
    pkgver="$(dpkg-query -W -f='${Version}' php5 2>/dev/null)"
    if dpkg --compare-versions "$pkgver" ge '5.6.36+dfsg-0+deb8u1'; then
      say "PATCHED: Debian php5 package version $pkgver includes the fixed level (>= 5.6.36+dfsg-0+deb8u1)."
      exit 0
    fi
  fi

  return 1
}

check_php_binary() {
  if ! have_cmd "$PHP_BIN"; then
    return 1
  fi

  raw="$("$PHP_BIN" -r 'echo PHP_VERSION;' 2>/dev/null || true)"
  if [ -z "$raw" ]; then
    return 1
  fi

  base="${raw%%-*}"
  major_minor_patch="$(printf '%s' "$base" | awk -F. '{print $1"."$2"."$3}')"
  series="$(printf '%s' "$base" | awk -F. '{print $1"."$2}')"

  if [ "$series" != "5.6" ]; then
    say "PATCHED: local PHP reports version $raw; plugin 109576 only applies to 5.6.x < 5.6.36."
    exit 0
  fi

  if ver_lt "$major_minor_patch" '5.6.36'; then
    say "VULNERABLE: local PHP reports version $raw (< 5.6.36)."
    exit 1
  fi

  say "PATCHED: local PHP reports version $raw (>= 5.6.36)."
  exit 0
}

check_rpm_hint() {
  if ! have_cmd rpm; then
    return 1
  fi

  # Best-effort only: RPM packaging/versioning varies heavily across vendors.
  for pkg in php php-cli php-fpm php-cgi php56-php php56-php-cli ea-php56 ea-php56-php-cli alt-php56-cli; do
    if rpm -q "$pkg" >/dev/null 2>&1; then
      nevra="$(rpm -q --qf '%{NAME} %{VERSION}-%{RELEASE}\n' "$pkg" 2>/dev/null | head -n1)"
      say "UNKNOWN: RPM package detected ($nevra). Verify vendor backports locally; remote banner checks are not authoritative on RPM-based systems."
      exit 2
    fi
  done

  return 1
}

check_dpkg_backports
check_php_binary
check_rpm_hint

say "UNKNOWN: could not validate a local PHP 5.6 binary or a known distro package backport."
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a validation-and-cleanup item, not a fire drill: first separate real exposure from banner noise with local package checks, then identify the subset of public-facing apps that actually use EXIF, iconv stream filters, LDAP, or PHAR error paths. Because the reassessed verdict is MEDIUM, the noisgate mitigation SLA is no mitigation SLA — go straight to the 365-day remediation window, and the noisgate remediation SLA is ≤ 365 days; if you confirm vulnerable internet-facing upload/image-processing workflows, pull those hosts forward inside that window rather than letting them sit at the back of the backlog.

Sources

  1. Tenable plugin 109576
  2. PHP 5 ChangeLog
  3. NVD CVE-2018-10549
  4. NVD CVE-2018-10547
  5. Ubuntu CVE-2018-10549
  6. Debian tracker CVE-2018-10546
  7. CISA Known Exploited Vulnerabilities Catalog
  8. Shodan CVEDB CVE-2018-10546
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.