← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:111230 · CWE-190 · Disclosed 2018-08-03

PHP 5

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

Like a bad odometer roll-over that only matters on an old compact car with a very specific dashboard option enabled

This issue maps to CVE-2018-14883 in PHP's EXIF handling. Upstream affected versions are PHP before 5.6.37, 7.0.x before 7.0.31, 7.1.x before 7.1.20, and 7.2.x before 7.2.8; your Tenable plugin is the 5.6.x < 5.6.37 slice. The bug is an integer overflow in exif_thumbnail_extract() that can lead to a heap-based out-of-bounds read when a PHP application parses attacker-controlled image metadata.

The vendor-style 7.5/High score overstates enterprise risk for patch prioritization. The decisive friction is that credible analysis from Red Hat says the overflow condition is 32-bit only, and the code path is reached only when the application actually invokes exif_thumbnail() or exif_read_data(..., ..., ..., true) on untrusted images; that is a much smaller population than 'every internet-facing PHP server.'

"This looks scary on paper, but real-world exploitation is narrow: 32-bit PHP plus EXIF parsing of attacker-controlled images."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a legacy PHP target

An attacker fingerprints a web stack with banner grabs or version leakage using tools like Nessus or nmap http-php-version. That only identifies a potentially affected runtime, not exploitability for this specific bug.
Conditions required:
  • Internet- or internal-network reachability to a PHP-backed application
  • Version disclosure or reliable fingerprinting of legacy PHP
Where this breaks in practice:
  • Many sites do not disclose exact PHP versions
  • The plugin title covers only 5.6.x, but exploitability still depends on architecture and application behavior
Detection/coverage: Good scanner coverage for exposed PHP versions; poor coverage for whether the vulnerable EXIF code path is actually reachable.
STEP 02

Get a crafted image into a parser path

The attacker needs an application feature that accepts or retrieves attacker-controlled JPEG/TIFF content and then parses EXIF metadata. A custom malformed file can be built with ordinary image tooling plus hand-edited EXIF fields; no turnkey public exploit kit stood out in source review.
Conditions required:
  • Application accepts user-supplied images or processes remote images
  • Attacker can influence the exact file bytes reaching EXIF parsing
Where this breaks in practice:
  • Plain PHP presence is not enough; the app must parse EXIF on untrusted content
  • Many upload paths resize, strip metadata, or store images without ever calling EXIF functions
Detection/coverage: Web scanners usually miss this because they do not know whether exif_read_data() or exif_thumbnail() is called server-side.
STEP 03

Hit the narrow vulnerable runtime state

The malformed image must be handled by PHP with the EXIF extension enabled and a code path that extracts thumbnails or reads EXIF with thumbnail extraction enabled. Red Hat's analysis says the integer overflow only occurs on 32-bit builds, which sharply narrows real exposure in modern enterprise fleets.
Conditions required:
  • PHP EXIF extension loaded
  • Application invokes exif_thumbnail() or exif_read_data() in the affected mode
  • Target PHP build is 32-bit
Where this breaks in practice:
  • Most modern server fleets are 64-bit
  • Many PHP apps never call EXIF functions at all
  • Some distributions ship EXIF as a module that can be disabled
Detection/coverage: Asset scanners can often see package/version, but not 32-bit runtime plus function reachability. Local host validation is better than remote scanning here.
STEP 04

Crash the worker, not own the box

If all prerequisites line up, exploitation can trigger an out-of-bounds read and likely process crash or service instability. Realistically this is an application DoS with at most limited memory disclosure potential, not a clean remote code execution path.
Conditions required:
  • Successful delivery of crafted EXIF values to the vulnerable function
  • Service behavior that surfaces a crash or restart impact
Where this breaks in practice:
  • Impact is mainly availability, and even that is process-scoped in many PHP-FPM deployments
  • No authoritative evidence of widespread in-the-wild abuse for this CVE was found
Detection/coverage: Look for PHP worker crashes, FPM restarts, segfaults, ASan-style faults in test, and anomalous image-processing failures.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo strong evidence of active exploitation found. I found no KEV listing and no credible campaign reporting tied to this CVE.
Proof-of-concept availabilityLimited. The public PHP bug has crash details and a patch trail, but I did not find a mature, turnkey public exploit repo worth treating as commodity weaponization.
EPSS0.20292 (20.29%) / 95th percentile per Tenable/BitSight-derived telemetry; that predicts attention, not guaranteed enterprise exploitability.
KEV statusNot listed in KEV based on available CVE aggregation views reviewed.
CVSS vectorCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = remotely triggerable *in theory*, but the vector ignores the need for an app-level EXIF parsing path and the 32-bit runtime constraint.
Affected versionsUpstream: <5.6.37, 7.0.x <7.0.31, 7.1.x <7.1.20, 7.2.x <7.2.8. Tenable plugin 111230 specifically flags the 5.6.x < 5.6.37 branch.
Fixed versionsUpstream fixes: 5.6.37, 7.0.31, 7.1.20, 7.2.8. Backports exist in distros like Ubuntu (php5 5.5.9+dfsg-1ubuntu4.26, php7.0 7.0.32-0ubuntu0.16.04.1, php7.2 7.2.10-0ubuntu0.18.04.1) and Debian (php5 5.6.37+dfsg-0+deb8u1, php7.0 7.0.33-0+deb9u1).
Exposure dataBroad internet PHP footprint, narrow actual exploit path. BitSight shows 2,580,613 observations tied to this CVE's product fingerprinting, with 748,803 in the US, but that does not mean all those assets are exploitable through EXIF parsing.
DisclosureBug submitted: 2018-06-07. CVE/NVD publication: 2018-08-03.
Reporting researcher / orgKaiyi Xu from DBAPPSecurity reported the PHP security bug.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.2/10)

The single biggest downgrade factor is that the exploitable condition is 32-bit only, which removes the vast majority of modern enterprise PHP servers from practical risk. On top of that, the attacker still needs a reachable application feature that parses untrusted EXIF data, so this is not a generic 'all PHP 5.6 web servers are easy DoS' situation.

HIGH Root-cause and affected-version assessment
HIGH 32-bit-only friction reducing real-world exposure
MEDIUM Absence of active exploitation evidence

Why this verdict

  • Downgrade: 32-bit runtime required. Red Hat explicitly notes the integer overflow condition only occurs on 32-bit builds, which is a major population cut.
  • Downgrade: application reachability is narrow. The bug is only reached when the app calls exif_thumbnail() or exif_read_data() in the relevant mode on attacker-controlled content.
  • Downgrade: impact is mostly DoS. The practical outcome is crash/instability or limited over-read, not straightforward remote code execution.

Why not higher?

I am not scoring this HIGH because the nominal network vector hides two compounding prerequisites: a 32-bit PHP runtime and a reachable EXIF parsing workflow on untrusted images. Those are exactly the kinds of real-world narrowing conditions that should drag a vulnerability down for fleet patch planning.

Why not lower?

I am not scoring this IGNORE because there is still a legitimate remote attack path in the subset of legacy environments that ingest user-supplied images and parse EXIF on 32-bit PHP. If you run old shared-hosting style stacks, embedded appliances, or odd legacy x86 builds, the bug is real enough to keep on the backlog.

05 · Compensating Control

What to do — in priority order.

  1. Disable EXIF where unused — If the application does not need EXIF parsing, stop loading the EXIF extension or remove the package/module. For a LOW verdict there is no SLA; treat as backlog hygiene, but do it opportunistically during the next config maintenance window because it removes this path entirely.
  2. Block EXIF functions in legacy apps — Use disable_functions = exif_read_data, exif_thumbnail, read_exif_data where compatibility allows. For this LOW item there is no SLA; treat as backlog hygiene, but it is a cheap guardrail on especially old shared PHP estates.
  3. Strip metadata on upload — Normalize or re-encode inbound images so attacker-controlled EXIF metadata never reaches PHP's EXIF parser. Again, no SLA for LOW, but this is the right engineering fix for image-processing workflows that cannot yet leave old PHP behind.
  4. Hunt 32-bit PHP first — Prioritize inventory for hosts where PHP is both 32-bit and EXIF-enabled; those are the only systems that materially matter for this CVE. For LOW, there is no SLA; treat as backlog hygiene, but this triage step prevents wasting cycles on the 64-bit majority.
What doesn't work
  • A generic WAF does not help much if the attack arrives as a legitimate image upload or file-processing workflow and the crash happens server-side in PHP EXIF parsing.
  • Simply hiding the X-Powered-By header does not reduce exploitability; it only makes fingerprinting slightly noisier.
  • EDR on the host may catch crash artifacts, but it does not prevent the vulnerable function from parsing malformed EXIF data.
06 · Verification

Crowdsourced verification payload.

Run this on the target host, not from an auditor workstation. Invoke it as bash check-cve-2018-14883.sh /usr/bin/php (or omit the path to use php from $PATH); no root is required, but you need access to the same PHP binary/config used by the application stack.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check-cve-2018-14883.sh
# Detects likely exposure to CVE-2018-14883 on a local PHP runtime.
# Outputs one of: 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

INFO="$($PHP_BIN -d display_errors=0 -r '
$ver = PHP_VERSION;
$intsize = PHP_INT_SIZE;
$arch = php_uname("m");
$loaded = extension_loaded("exif") ? "yes" : "no";
$f1 = function_exists("exif_read_data") ? "yes" : "no";
$f2 = function_exists("exif_thumbnail") ? "yes" : "no";
echo "version=$ver\n";
echo "int_size=$intsize\n";
echo "arch=$arch\n";
echo "exif_loaded=$loaded\n";
echo "exif_read_data=$f1\n";
echo "exif_thumbnail=$f2\n";
' 2>/dev/null)"

if [ -z "$INFO" ]; then
  echo "UNKNOWN - unable to query PHP runtime"
  exit 2
fi

VERSION="$(printf '%s
' "$INFO" | awk -F= '/^version=/{print $2}')"
INT_SIZE="$(printf '%s
' "$INFO" | awk -F= '/^int_size=/{print $2}')"
ARCH="$(printf '%s
' "$INFO" | awk -F= '/^arch=/{print $2}')"
EXIF_LOADED="$(printf '%s
' "$INFO" | awk -F= '/^exif_loaded=/{print $2}')"
EXIF_READ="$(printf '%s
' "$INFO" | awk -F= '/^exif_read_data=/{print $2}')"
EXIF_THUMB="$(printf '%s
' "$INFO" | awk -F= '/^exif_thumbnail=/{print $2}')"

vp_lt() {
  # returns 0 if $1 < $2
  "$PHP_BIN" -r 'exit(version_compare($argv[1], $argv[2], "<") ? 0 : 1);' "$1" "$2"
}

is_affected_version=1
case "$VERSION" in
  5.6.*)
    if vp_lt "$VERSION" "5.6.37"; then is_affected_version=0; fi
    ;;
  7.0.*)
    if vp_lt "$VERSION" "7.0.31"; then is_affected_version=0; fi
    ;;
  7.1.*)
    if vp_lt "$VERSION" "7.1.20"; then is_affected_version=0; fi
    ;;
  7.2.*)
    if vp_lt "$VERSION" "7.2.8"; then is_affected_version=0; fi
    ;;
  *)
    is_affected_version=1
    ;;
esac

if [ "$is_affected_version" -ne 0 ]; then
  echo "PATCHED - PHP version $VERSION is outside the upstream affected ranges for CVE-2018-14883"
  exit 0
fi

if [ "$EXIF_LOADED" != "yes" ] || { [ "$EXIF_READ" != "yes" ] && [ "$EXIF_THUMB" != "yes" ]; }; then
  echo "UNKNOWN - version $VERSION is in an affected range, but EXIF does not appear reachable in this runtime"
  exit 2
fi

if [ "$INT_SIZE" = "4" ]; then
  echo "VULNERABLE - PHP $VERSION is in the affected range, EXIF is enabled, and runtime appears 32-bit ($ARCH)"
  exit 1
fi

if [ "$INT_SIZE" = "8" ]; then
  echo "UNKNOWN - PHP $VERSION is in the affected range, but runtime appears 64-bit ($ARCH); Red Hat analysis says the overflow condition is 32-bit only"
  exit 2
fi

echo "UNKNOWN - could not determine architecture/risk precisely for PHP $VERSION"
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not mass-escalate this across every PHP 5.6 finding. First, inventory the narrow subset that is actually interesting: 32-bit PHP, EXIF enabled, and applications that parse untrusted image metadata. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA—treat it as backlog hygiene—so document the downgrade on 64-bit or EXIF-unused systems, disable EXIF parsing where easy, and fold actual PHP updates into the next planned legacy-PHP maintenance cycle; only expedite if you discover a real 32-bit internet-facing upload workflow.

Sources

  1. Tenable Nessus Plugin 111230
  2. NVD CVE-2018-14883
  3. PHP security bug 76423
  4. PHP 5 ChangeLog 5.6.37
  5. Red Hat Bugzilla analysis
  6. Ubuntu CVE page
  7. Debian security tracker
  8. BitSight observation footprint
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.