← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:117497 · CWE-79 · Disclosed 2018-09-13

PHP 5

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

This is less an open front door than a bent mail slot that only matters if someone still uses the old porch

CVE-2018-17082 is a bug in PHP's Apache2 handler (sapi/apache2handler) where a crafted Transfer-Encoding: chunked request can cause attacker-controlled request body data to be echoed back in the HTTP response. For this specific Tenable finding, the directly affected upstream range is PHP 5.6.x before 5.6.38; broader upstream exposure also covered 7.0.x < 7.0.32, 7.1.x < 7.1.22, and 7.2.x < 7.2.10.

The vendor's MEDIUM label is defensible in CVSS terms, but it overstates operational urgency for enterprise patch queues. Real exploitation depends on a brittle chain: the target must be using Apache mod_php rather than PHP-FPM/CGI, the malformed chunked request has to survive intermediaries, and impact usually needs either victim browser rendering or a cache-poisoning side path rather than direct server compromise.

"Remote on paper, narrow and awkward in practice: this is a legacy mod_php edge case, not a fleet-fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a mod_php target

The attacker first needs a PHP site running through Apache's embedded handler rather than PHP-FPM or CGI. Tenable itself models this with required KB items for both www/PHP and installed_sw/Apache, because this bug sits in sapi_apache2.c, not generic PHP request handling.
Conditions required:
  • Internet or internal network reachability to the web server
  • Apache HTTP Server in use
  • PHP loaded via Apache module / apache2handler path
Where this breaks in practice:
  • A large share of modern PHP estates use PHP-FPM behind Apache or Nginx instead of mod_php
  • Banner-based scanners often overcall version exposure without proving request-path reachability
  • Reverse proxies and CDNs can terminate or normalize requests before Apache sees the malformed body
Detection/coverage: Version scanners catch the package/banner state well; they do not prove the vulnerable handler is reachable end-to-end.
STEP 02

Send malformed chunked body PoC

Using the public reproducer from PHP bug #76582, the attacker sends a crafted POST with Transfer-Encoding: chunked so the request body is reflected into the response. Tenable marks Exploit Available: true, but this is better read as public PoC/reproducer exists, not as turnkey weaponization.
Conditions required:
  • Ability to send raw HTTP/1.1 requests
  • Target path handled by vulnerable PHP Apache module
  • Malformed chunked encoding reaches Apache unchanged
Where this breaks in practice:
  • Many WAFs, load balancers, CDNs, and modern front ends reject malformed chunked traffic
  • HTTP normalization at proxies often breaks the PoC
  • This is not a one-click browser exploit; it is a crafted protocol-level request
Detection/coverage: A WAF or reverse proxy with strict HTTP parsing should log or block malformed Transfer-Encoding: chunked requests; generic vuln scanners may only flag by version.
STEP 03

Turn reflection into usable script execution

The echoed body only matters if a browser renders it in the origin context or if an intermediary caches the poisoned response and serves it to later users. Practically, the more credible story is cache poisoning / response confusion, not clean reflected XSS against arbitrary visitors.
Conditions required:
  • Victim user interaction or shared cache behavior
  • Renderable response context in a browser
  • Origin/proxy cache stores and re-serves the malicious response
Where this breaks in practice:
  • Many responses here are error-like or malformed and never become a stable victim-facing page
  • Dynamic/error responses are often not cached
  • Browsers, CSP, and cache controls can reduce or kill the usable impact
Detection/coverage: Proxy/CDN logs and cache telemetry are more useful than endpoint telemetry; there is no reliable host-level IOC for the reflection alone.
STEP 04

Steal session or act as victim

If the attacker gets JavaScript to execute in-origin, they can read page data available to the browser and act with the victim's session. The impact is still client-side and scoped to that application context; there is no direct path to server-side code execution from this CVE alone.
Conditions required:
  • A victim session worth stealing or abusing
  • Same-origin script execution actually achieved
  • Application lacks additional defenses that limit session abuse
Where this breaks in practice:
  • No server-side RCE, privilege escalation, or auth bypass is inherent here
  • Short-lived cookies, HttpOnly, CSRF protections, and step-up auth limit post-XSS payoff
  • The exploit chain is fragile enough that broad internet spray is unattractive
Detection/coverage: Browser-side abuse is hard to confirm after the fact; look for anomalous session use, impossible travel, or suspicious admin actions rather than malware-style artifacts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild status*Inference:* I found no credible public evidence of active exploitation campaigns for CVE-2018-17082 in the vendor, NVD, or Tenable material reviewed, and no matching entry surfaced in the CISA KEV catalog.
PoC availabilityPublic reproducer exists. The original PHP security bug #76582 includes repro details, and Tenable plugin 117497 explicitly says Exploit Available: true.
EPSSA recent aggregator view reflecting FIRST EPSS showed 0.43% probability, 71.7th percentile when crawled 3 weeks ago: Feedly CVE page. Treat that as low exploit pressure, not zero.
KEV statusNot KEV-listed based on this assessment's review of the CISA catalog; no due date applies from KEV.
CVSS vector reality checkNVD scores it 6.1 / MEDIUM with CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (NVD). The important downgrader is UI:R: somebody has to consume the poisoned response for this to matter.
Affected versionsUpstream affected ranges are PHP < 5.6.38, 7.0.x < 7.0.32, 7.1.x < 7.1.22, and 7.2.x < 7.2.10 in the Apache2 handler path (NVD, PHP changelog).
Fixed versions and backportsUpstream fixed in 5.6.38 for this finding. Distros may backport without matching upstream version strings; for example Ubuntu lists fixes at 5.5.9+dfsg-1ubuntu4.26, 7.0.32-0ubuntu0.16.04.1, and 7.2.10-0ubuntu0.18.04.1 (Ubuntu CVE page).
Exposure/scanning realityThis is not cleanly internet-fingerprintable by Shodan/Censys-style banners because exploitability depends on request handling behavior, not just a product string. Even Tenable's Nessus plugin is fundamentally banner/version-based and requires Apache presence in KB items (plugin 117497).
Disclosure timelineBug submitted 2018-07-05 (PHP bug #76582); upstream fix shipped in PHP 5.6.38 on 2018-09-13 (PHP changelog); NVD published the CVE on 2018-09-16 (NVD).
Reporter / root causeReported by Prashanth Varma via PHP security bug #76582. The patch is a one-line cleanup in sapi/apache2handler/sapi_apache2.c to clean the brigade state (GitHub commit 23b0577).
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive friction is attack-path brittleness: this is only relevant on Apache mod_php and still needs a malformed chunked request to survive the front end and become a browser-usable response. That sharply narrows both reachable population and real attacker payoff compared with what a generic remote-XSS CVSS label implies.

HIGH Affected upstream versions and fixed releases
MEDIUM Real-world exploitability in modern enterprise edge stacks
HIGH Downgrade from vendor MEDIUM to operational LOW

Why this verdict

  • Requires the old handler path: this bug lives in sapi/apache2handler; PHP-FPM/CGI estates don't carry the same exposure, which cuts the reachable population hard.
  • Needs malformed HTTP to reach origin: the attacker must deliver a crafted Transfer-Encoding: chunked request through proxies, WAFs, CDNs, and load balancers that commonly normalize or reject it.
  • Impact is client-side, not server-side: even when triggered, the endgame is browser-context script execution or cache poisoning, not direct RCE, auth bypass, or data-at-rest compromise on the server.

Why not higher?

This is not a pre-auth server takeover and not even a reliable reflected XSS in the usual sense. It depends on user interaction or cache behavior after a malformed request reaches a specific legacy deployment model, which is too much friction for a HIGH or CRITICAL patch priority.

Why not lower?

It is still unauthenticated remote input against an internet-facing surface, and if the chain lands, the attacker can execute script in the application's origin context. On legacy estates still running Apache mod_php and weak cache controls, there is enough real residual risk that this should stay above IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Block malformed chunked requests at the edge — Enforce strict HTTP parsing on WAFs, reverse proxies, and load balancers so malformed Transfer-Encoding: chunked traffic never reaches Apache. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene unless the asset is especially sensitive or internet-exposed legacy PHP.
  2. Disable caching of dynamic and error responses — Reduce the more plausible abuse path by ensuring dynamic pages and error responses are not stored by shared proxies/CDNs unless explicitly intended. For a LOW verdict there is no mitigation SLA; fold this into your normal web-tier hardening cycle.
  3. Retire mod_php and legacy PHP 5.6 — Move Apache+PHP deployments to supported runtimes, ideally PHP-FPM behind a modern front end, and eliminate PHP 5.6 entirely. For a LOW verdict there is no mitigation SLA; schedule it as backlog hygiene, but treat the broader EOL platform risk separately from this CVE.
What doesn't work
  • EDR on the web server won't stop the core issue; this is request/response handling and browser-side impact, not host malware execution.
  • MFA does not prevent the vulnerability from triggering; it only reduces the value of stolen sessions in some workflows.
  • Version-only allowlists in scanners can create false urgency or false confidence because they do not prove the vulnerable Apache handler path is actually in use.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux web server, not from an auditor workstation. Invoke it as sudo bash ./check-cve-2018-17082.sh; root is recommended so Apache module queries succeed, but it will still try a best-effort check without full privileges.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2018-17082.sh
# Determine likely exposure to CVE-2018-17082 for Apache+PHP hosts.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=vulnerable, 0=patched/not-applicable, 2=unknown

set -u

say() {
  echo "$1"
}

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

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

apache_cmd=""
for c in apache2ctl apachectl httpd; do
  if have_cmd "$c"; then
    apache_cmd="$c"
    break
  fi
done

if [ -z "$apache_cmd" ]; then
  # No Apache control binary found; this Tenable finding is Apache-specific.
  say "PATCHED"
  exit 0
fi

mods="$($apache_cmd -M 2>/dev/null || true)"
if [ -z "$mods" ]; then
  # Could not inspect modules; continue, but confidence drops.
  mods=""
fi

# Check whether Apache appears to load a PHP module.
if ! printf '%s' "$mods" | grep -Eiq 'php[0-9_]*_module|php_module'; then
  # No mod_php detected; CVE-2018-17082 is in sapi/apache2handler.
  say "PATCHED"
  exit 0
fi

# Try distro package checks first for known backports.
if have_cmd dpkg-query; then
  # Ubuntu/Debian backport examples from vendor advisory data.
  if dpkg-query -W -f='${Package} ${Version}\n' 2>/dev/null | grep -q '^php5 '; then
    pkgver="$(dpkg-query -W -f='${Version}' php5 2>/dev/null || true)"
    if [ -n "$pkgver" ] && dpkg --compare-versions "$pkgver" ge '5.5.9+dfsg-1ubuntu4.26'; then
      say "PATCHED"
      exit 0
    fi
  fi
fi

php_ver=""
if have_cmd php-config; then
  php_ver="$(php-config --version 2>/dev/null || true)"
fi
if [ -z "$php_ver" ] && have_cmd php; then
  php_ver="$(php -r 'echo PHP_VERSION;' 2>/dev/null || true)"
fi

if [ -z "$php_ver" ]; then
  say "UNKNOWN"
  exit 2
fi

# Strip suffixes such as -ubuntu or extra build metadata if present.
base_ver="$(printf '%s' "$php_ver" | sed 's/[^0-9.].*$//')"

case "$base_ver" in
  5.6.*)
    if version_lt "$base_ver" '5.6.38'; then
      say "VULNERABLE"
      exit 1
    else
      say "PATCHED"
      exit 0
    fi
    ;;
  7.0.*)
    if version_lt "$base_ver" '7.0.32'; then
      say "VULNERABLE"
      exit 1
    else
      say "PATCHED"
      exit 0
    fi
    ;;
  7.1.*)
    if version_lt "$base_ver" '7.1.22'; then
      say "VULNERABLE"
      exit 1
    else
      say "PATCHED"
      exit 0
    fi
    ;;
  7.2.*)
    if version_lt "$base_ver" '7.2.10'; then
      say "VULNERABLE"
      exit 1
    else
      say "PATCHED"
      exit 0
    fi
    ;;
  *)
    # This specific CVE does not affect other major/minor lines in the cited advisories.
    say "PATCHED"
    exit 0
    ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency window on plugin 117497 by itself. If the host is truly running Apache mod_php on PHP 5.6.x < 5.6.38, put it in backlog hygiene, verify whether any shared cache could store malformed/error responses, and roll the fix into your broader PHP 5.6 retirement work; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — this should be closed through your normal legacy-platform upgrade cycle rather than a rush patch.

Sources

  1. Tenable Nessus plugin 117497
  2. NVD CVE-2018-17082
  3. PHP security bug #76582
  4. PHP 5 changelog (5.6.38 fix)
  5. PHP patch commit 23b0577
  6. Ubuntu CVE-2018-17082 advisory
  7. Tenable blog on the issue
  8. CISA Known Exploited Vulnerabilities Catalog
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.