PHP Unsupported Version Detection: How to Upgrade PHP and Close Nessus 58987

PHP Unsupported Version Detection is a Nessus finding (plugin 58987) meaning a web server runs a PHP branch the PHP project no longer patches, such as 7.4, 8.0 or 8.1. Fix it by upgrading to a supported branch (ideally 8.3 or newer in late 2026), pointing PHP-FPM or mod_php at it, and removing the old version.

What the scanner is actually detecting

This finding carries no CVE. The scanner reads the PHP version exposed by a web server and compares the branch with the PHP project’s end-of-life dates.

Greenbone (OpenVAS) reports the same condition through its own PHP end-of-life NVT. Nessus plugin 58987 (php_unsupported.nasl) requires the www/PHP knowledge base item, so it only fires after Nessus has identified PHP on a web port. It does not test for any specific vulnerability. The version comes from what the web server reveals, for example the X-Powered-By: PHP/7.4.33 header that PHP sends while expose_php is enabled, which is the default. Tenable’s solution is simply to upgrade to a currently supported PHP version.

Real-world risk

The finding is a statement about patch availability, not proof of an exploitable bug. It still matters:

• No upstream fixes: php.net gives each branch two years of active support and two years of security-only support, then ends it. Branch 8.1 reached end of life on 31 December 2025, joining 7.4 and 8.0.
• Real gaps appear: CVE-2024-4577, a PHP-CGI argument injection on Windows, was fixed only in 8.1.29, 8.2.20 and 8.3.8. Branch 8.0 and older got no fixed release. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 12 June 2024.
• Exposure: PHP runs the application code behind the web server, so internet-facing sites should be upgraded first.

The honest caveat: Red Hat and Canonical backport security fixes into the PHP builds they ship. On those hosts the upstream branch number overstates the risk, and the real question is whether the vendor still supports the package.

How to confirm it on the host

# What the web server advertises (only while expose_php is on)
curl -sI https://www.example.com/ | grep -i x-powered-by

# CLI version, FPM services and installed packages
php -v
systemctl list-units --type=service 'php*'
rpm -q php-cli php-fpm                   # RHEL family
dnf module list --enabled php            # RHEL 8 and 9
dpkg -l 'php*' | grep '^ii'              # Debian and Ubuntu
a2query -m | grep php; a2query -c | grep fpm   # Debian and Ubuntu Apache handler

The CLI and the web server can run different versions. To see what a site really runs, place a temporary file in its document root, request it, and delete it immediately:

echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/ver.php
curl -s http://localhost/ver.php
sudo rm /var/www/html/ver.php

Also note which repository the build came from, because a Red Hat or Ubuntu main package changes the analysis.

How to fix it

Choose the target branch

These are the supported branches on php.net as of September 2026. Branch 8.2 drops off at the end of 2026, so moving to it now only schedules the next finding. Target 8.4 or 8.5 where your application supports it, or 8.3 at minimum.

RHEL, AlmaLinux and Rocky Linux

Red Hat ships PHP as Application Streams. Its life cycle page lists PHP 7.4 (Full Life) and 8.2 (retiring May 2029) for RHEL 8; 8.0 (Full Life), 8.2 and 8.3 (both retiring May 2029) for RHEL 9; and 8.3 plus 8.4 (from 10.2) for RHEL 10. On a fully updated system, Red Hat documents this stream change (its docs write yum, the same tool as dnf on RHEL 8):

sudo dnf distro-sync             # should report nothing to do first
sudo dnf module reset php
sudo dnf module enable php:8.2   # or php:8.3 on RHEL 9
sudo dnf distro-sync
sudo systemctl restart php-fpm httpd   # or nginx

Reinstall PECL or other binary extensions afterwards. Red Hat supports its streams past the php.net dates, so version-based scanners will flag RHEL’s 8.2 again after 31 December 2026 even while Red Hat patches it.

For a newer branch, the community Remi repository publishes current ones. Its configuration wizard gives these commands for RHEL 9 and PHP 8.4. On RHEL 8, change the 9 to 8 in each URL and repository name. On AlmaLinux or Rocky Linux, replace the subscription-manager line with sudo dnf config-manager --set-enabled crb (EL 9) or --set-enabled powertools (EL 8).

sudo subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
sudo dnf module switch-to php:remi-8.4
php --version
php --modules

The trade-off is support: PHP now comes from a community repository rather than Red Hat, so you own its update cadence.

Debian and Ubuntu

Each release pins one branch: Debian 11 ships 7.4, Debian 12 ships 8.2 and Debian 13 ships 8.4; Ubuntu 22.04 ships 8.1, 24.04 ships 8.3 and 26.04 ships 8.5. A release upgrade is often the cleanest fix. Otherwise, Ondřej Surý’s repositories install newer branches alongside the old one. On Debian, the repository README uses:

sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl
sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt-get update

On Ubuntu 22.04 or 24.04, use sudo add-apt-repository ppa:ondrej/php followed by sudo apt update. Then list the old version’s extensions and install the same set for the new branch:

dpkg-query -W -f='${Package}n' 'php8.1*'
sudo apt install php8.4-fpm php8.4-cli php8.4-mysql php8.4-xml php8.4-mbstring php8.4-curl

Compare, rather than copy, /etc/php/8.1/fpm/php.ini and /etc/php/8.1/fpm/pool.d/ against the new /etc/php/8.4/ tree. Then switch the handler:

# Apache with PHP-FPM
sudo a2enmod proxy_fcgi setenvif
sudo a2disconf php8.1-fpm
sudo a2enconf php8.4-fpm
sudo systemctl reload apache2

# Apache with mod_php
sudo a2dismod php8.1
sudo a2enmod php8.4
sudo systemctl restart apache2

# nginx: point fastcgi_pass at the new pool's listen address
grep '^listen' /etc/php/8.4/fpm/pool.d/www.conf
sudo nginx -t && sudo systemctl reload nginx

# Default CLI version
sudo update-alternatives --config php

Containers and appliances

For containers, change the PHP base image tag and rebuild; an upgrade inside a running container does not persist. For a vendor appliance, the fix is the vendor release that bundles a supported PHP.

How to verify the fix and rescan

1. Request the temporary version page again, or check the X-Powered-By header, on every virtual host, not only the default site.
2. Stop the old runtime with sudo systemctl disable --now php8.1-fpm.
3. After a soak period, remove the old packages on Debian and Ubuntu: sudo apt purge $(dpkg-query -W -f='${Package}n' 'php8.1*'). On RHEL the stream change already replaced them; confirm with rpm -q php-cli.
4. Rescan. In Nessus, PHP Version Detection (plugin 48243) should show the new version and plugin 58987 should be gone. Rerun Tenable WAS or Greenbone scans the same way.

What can break and how to roll back

• Application code: PHP 8.0 removed create_function() and each(), changed string to number comparisons and turned a number of warnings into Error exceptions. Read the php.net migration guide for every branch you skip and test the application first.
• Extensions: PECL modules and commercial loaders must be built for the new branch, or pages that use them fail.
• Configuration: on Debian and Ubuntu, php.ini and pool settings do not follow the upgrade automatically. On RHEL, locally changed files can end up beside new .rpmnew copies.

With side-by-side packages on Debian and Ubuntu, keep the old branch installed until the application runs cleanly; rollback means re-enabling the old conf, module or socket and reloading the web server. On RHEL, snapshot or back up before the stream change: Red Hat states that downgrading packages with yum history undo or yum history rollback is not supported, so a restore is the reliable path.

Common false positive reasons

• Vendor-supported builds: Red Hat lists PHP 7.4 on RHEL 8 and PHP 8.0 on RHEL 9 as Full Life Application Streams, and Ubuntu 22.04 still publishes security updates for php8.1 in main (for example 8.1.2-1ubuntu2.26). Plugin 58987 judges only the upstream branch. Confirm the package is from the vendor repository and current, check recent CVE fixes with rpm -q --changelog php-cli | grep -i cve | head or apt changelog php8.1-cli | grep -i cve | head, and document the exception. See why backported patches trigger false positives for the evidence to keep.
• Header from another system: a reverse proxy can pass through a backend’s X-Powered-By header, so the finding lands on the front-end address.
• Stale results: the report predates the upgrade, or the IP now belongs to a rebuilt host.

Two cases look like false positives but are not: a new CLI version while a site still runs an old FPM pool, and a finding that vanished only because expose_php = Off hid the version. More patterns are in common causes of vulnerability scanner false positives.

FAQ

Is PHP 8.2 still supported?

Yes, for security fixes only, until 31 December 2026 according to php.net. Choose 8.3 or newer if you can.

Does setting expose_php = Off fix the finding?

No. It hides the version from the response header and may stop remote detection, but the unsupported runtime is still there.

Is PHP 7.4 on RHEL 8 really unsupported?

Not by Red Hat. It is a Full Life Application Stream for RHEL 8, so Red Hat still ships fixes. Keep it updated from Red Hat repositories and document the exception, or move to a newer stream.

Why does a finding with no CVE rate Critical?

Tenable scores the plugin at CVSS 10.0 because unsupported software is expected to accumulate unpatched vulnerabilities. Prioritize by exposure, starting with internet-facing sites.

Tracking this finding across many hosts

PHP upgrades usually land host by host as each application is tested. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results via an uploaded .nessus export), so you can follow which hosts still report PHP Unsupported Version Detection. Its AI triage can suggest a false positive with evidence, such as a vendor-backported build, while a human makes the final call, and per-finding retest for Nessus confirms closure after each upgrade.

Sources

• Tenable: Nessus plugin 58987, PHP Unsupported Version Detection
• Tenable: Web App Scanning plugin 98230, PHP Unsupported Version
• PHP: Supported Versions
• Red Hat: RHEL Application Streams Life Cycle
• PHP security advisory GHSA-3qgc-jrrr-25jv (CVE-2024-4577)