Unsupported software · Software and cloud

PHP Unsupported Version Detection: Upgrade, Patch, or Document It

Your scanner flagged PHP Unsupported Version Detection (Nessus 58987). What it means, why PHP2Shell raises the stakes, and how to upgrade or document it.

What the scanner said

PHP Unsupported Version DetectionPHP Unsupported VersionUnsupported PHP version

Your scanner read the PHP version your web server reports, usually from the X-Powered-By header, and found a branch the PHP project no longer patches. Tenable reports it as plugin 58987 and rates it Critical. As of October 2026, PHP supports 8.2 through 8.5. PHP 8.1 and older are past end of life, and 8.2 joins them on December 31, 2026. The finding covers every flaw disclosed after a branch's end of life, including PHP2Shell (CVE-2026-109618 and CVE-2026-109619), which allows unauthenticated remote code execution, with exploitation attempts reported since disclosure.

Why it matters

Unsupported software is a finding on its own, before any single CVE. NIST 800-53 SA-22 asks you to replace components that no longer get vendor support, or to approve and document an alternative source of support. Approved Scanning Vendors treat unsupported software as an automatic PCI scan failure. NERC CIP-007 patch management needs a patch source for every applicable asset, and an end-of-life branch no longer has one. An operator's supplier review asks the same question in plainer words.

PHP2Shell raises the stakes. An attacker can trigger it with one oversized POST request, which PHP parses before your application code or its login runs, so authentication doesn't protect the site. Every PHP setup that serves web requests is exposed, including PHP-FPM, Apache with mod_php, and php-cgi.

The fix

Move every PHP install to a supported branch. Choose 8.4 or 8.5: 8.2 reaches end of life on December 31, 2026, and 8.3 a year later. At minimum, run the PHP2Shell fixes: 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

Find every runtime first. A server can run more than one, and the web server's PHP can differ from the command line's.

php -v
php-fpm -v                          # or php-fpm8.x -v
curl -sI https://<host> | grep -i x-powered-by

If PHP came from your operating system vendor, its patched package is also a fix. Red Hat, Ubuntu, and Debian backport security fixes into older version numbers, so check the vendor's advisory for CVE-2026-109618 before you change branches.

A jump from PHP 7 to PHP 8 can break application code. Scan it before you switch.

phpcs -p --standard=PHPCompatibility --runtime-set testVersion 8.4 /path/to/app

Setting expose_php = Off hides the version from scanners and fixes nothing. Do it after the upgrade, as hygiene.

Verify. Run php -v for each runtime, check the X-Powered-By header (or confirm it's gone), and rerun your scanner. Keep the before and after output as the evidence that the finding is closed.

In practice: WordPress in the official Docker image

Tags such as wordpress:php8.3-apache run PHP under Apache mod_php, the setup where PHP2Shell is reachable before WordPress itself loads.

Cut public exposure while you patch. Remove the tunnel or proxy route, or put an access gate in front. A WordPress described as admin-only is often still reachable from the internet.
Check for compromise before you patch. Look for POST requests outside the endpoints WordPress normally uses (wp-login.php, admin-ajax.php, wp-cron.php, the REST API), and for segfaults, "Allowed memory size" errors, or Apache child exits. Behind a tunnel or proxy, the logs show the proxy's address, so pull client IPs from the proxy.
Pull the rebuilt tag and recreate the container. Docker Hub rebuilt the PHP 8.x WordPress images with the fixed PHP on October 21, 2026. Restarting an existing container keeps the old image. Confirm with docker exec <container> php -v.
Rotate the WordPress salts and the database password. PHP2Shell can leak worker memory, so treat anything in memory as exposed. New salts sign everyone out.
Pin the image by digest, so the next update is a deliberate change.

When you can't fix it

Some applications can't move yet: a vendor product certified only on an old branch, a line-of-business app nobody has ported, or an appliance with PHP built in. Your named owner chooses one treatment.

Remediate by upgrading the application or replacing it, with a dated plan.
Mitigate with a supported source of patches (your OS vendor's package, the PHP security team's source backports, or a commercial extended-support build), and cut the exposure around it. Keep the host off the internet or behind an authenticating proxy, restrict it to an allowlist of client addresses, and cap request body size at the web server or proxy in front. The PHP project says no configuration change fully closes PHP2Shell, so these controls narrow the risk until the upgrade lands.
Accept with documented compensating controls: the host, why it can't change, the controls above, the source of patches, the owner, a review date, and a replacement date. SA-22 expects that approval in writing. For a PCI ASV scan, give the ASV that record through its dispute process. The ASV reviews the evidence and decides.

The post Compensating Controls for Legacy Systems covers which controls carry weight and how to write the record an assessor accepts.

Where it lands in the Risk Register

Finding	Treatment	Owner	Evidence
Unsupported PHP branch on a named host	Remediate, mitigate, or accept (the owner decides)	Named by you	php -v and scanner output before and after. Maps to NIST 800-53 SA-22 and SI-2, and PCI DSS 6.3.3 and 12.3.4.

Common questions

Is PHP 8.2 still supported?

For security fixes only, until December 31, 2026. After that the PHP project issues no patches for it, and scanners will start flagging 8.2 hosts too. Plan the move to 8.4 or 8.5 now.

Can I get patches for PHP 7.4, 8.0, or 8.1?

For PHP2Shell, the PHP security team published minimal source backports for 7.4 through 8.1, with no official releases. Operating system vendors and commercial extended-support builds may carry fixes for those branches. PHP 7.3 and older have no fix from the PHP project.

Does hiding the version close the finding?

Setting expose_php = Off can stop a remote scanner from reading the version, and the runtime underneath stays unsupported. An assessor asks what runs on the host, so plan the upgrade and treat the setting as hygiene after it.