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.
4 steps from start to impact.
Find a PHP host by banner
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.- PHP version is exposed via HTTP headers, CGI output, or other banner data
- The host is reachable from the attacker position
- 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
Reach a vulnerable application sink
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.- 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
- 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
Trigger parser failure or browser-side script execution
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.- Malformed input must survive application validation
- The vulnerable parser must process the payload
- For XSS, a victim user must render the malicious response
- 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
Convert bug into business impact
- The target application must expose the affected workflow to untrusted users
- Operational protections must fail to contain the result
- 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
The supporting signals.
| Actual scanner baseline | Tenable 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 status | I 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 availability | Public 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. |
| EPSS | A 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 status | Not listed in the CISA Known Exploited Vulnerabilities catalog as checked against the public catalog URL. |
| CVSS vector and interpretation | The 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 versions | Upstream 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 backports | Upstream 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 reality | Exposure 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 context | Upstream 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. |
noisgate verdict.
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.
Why this verdict
- Down from 8.8 because the lead CVE is not a turnkey takeover: the score is anchored to
CVE-2018-10549, anEXIFout-of-bounds read, but real exploitation still needs an app to parse attacker-supplied image metadata withexif_read_data(). - More downward pressure from attacker position and app reachability:
CVE-2018-10548effectively needs a malicious LDAP backend,CVE-2018-10546needs a specificiconvstream-filter code path, andCVE-2018-10547needs user interaction on a.pharerror page. - Remote population is narrower than the plugin suggests: Tenable
109576is 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.
What to do — in priority order.
- 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.
- Constrain risky parsing paths — If the host is truly on vulnerable PHP, review whether apps process untrusted JPEG metadata with
exif_read_data(), useconvert.iconvon attacker-controlled streams, or expose.pharrequest paths. For MEDIUM, there is no mitigation SLA; fold this into the same application-hardening workstream used for normal change windows. - Limit PHP extension surface — Disable unused extensions like
ldaporexifin 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. - Prefer supported runtimes over point fixes — If you confirm vulnerable
5.6.x, do not stop at proving5.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.
- 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.
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.
#!/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
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.