In short: To check the PHP version, php -v is not enough. You need to know which PHP version the web server really uses, whether the package contains the fix, including as a backport with an old number, and whether all processes were restarted after the update. PHP2Shell is fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Why the version number alone is not enough
There is a clear list of fixed versions for PHP2Shell. In practice, three situations nevertheless lead to misjudgments:
- Multiple installations: The command line shows PHP 8.3, but the website runs through a pool with PHP 8.1.
- Backports: Distributions and hosting providers sometimes apply fixes into existing packages. Plesk, for example, then keeps showing 8.2.34 although it is patched.
- Old processes: The new files are on disk, but the running workers still date from before.
For management and non-technical readers, a simple rule of thumb helps: do not only ask "Which PHP version do we have?", but "Is PHP2Shell closed on all servers, and how can we tell?" A reliable answer contains three pieces of evidence: version or backport, package version and time of the restart.
The technical check therefore has three steps: version, package version, running processes. The commands below are read-only. Package and service names differ by distribution, PHP source and hosting interface; the examples assume PHP 8.3.
Checking the PHP version on the command line
php -v # command-line version
ls /etc/php/ 2>/dev/null # Debian/Ubuntu: installed branches
php-fpm8.3 -v # version of the FPM binary (name differs by distribution)
php -i | grep -E "^PHP Version|Server API|Loaded Configuration File"
On RHEL, AlmaLinux or Rocky, the FPM binary is usually called php-fpm; with Software Collections or third-party sources, further versions sit in their own paths. Plesk and cPanel bring their own PHP installations that exist alongside the system PHP. How to proceed there is described on the pages about Plesk and cPanel.
The most reliable way to see which PHP version a website uses in the web context is the pool or VirtualHost configuration or the hosting interface. A phpinfo page also shows it; set it up only briefly, with access protection and a random name, and delete it immediately afterwards.
With shared hosting, you usually have no access to the command line. In that case the hosting interface shows the configured PHP version per website. Whether a backport has been applied and restarted is rarely stated there, though. Here the written confirmation from the hosting provider is the reliable way.
Checking package version and backports
The package version shows what your distribution has actually shipped:
# Debian/Ubuntu
apt policy php8.3-fpm
apt changelog php8.3-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"
# RHEL, AlmaLinux, Rocky, Fedora
dnf info php-fpm
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"
If one of the CVE numbers appears in the changelog, the backport is contained in the installed package. If the entry is missing, that is not yet proof of a vulnerability: some package maintainers word changelogs differently. In that case, compare the package version with your distribution's security advisories or ask the provider. You will find a template for this request at How to ask your hosting provider about the patch status.
Important: check every installed PHP package, not just the first. On servers with several branches, one is often patched and another is not.
Is the new version really running?
An update only takes effect once all PHP processes have been restarted. Compare the start time of the running processes with the time of the update:
ps -o pid,lstart,cmd -C php-fpm8.3 # start time of the FPM processes
systemctl status php8.3-fpm # since when the service has been running
needrestart -r l # Debian/Ubuntu, if installed: shows outdated processes
If the start time is before the update, old processes are still running. With Apache and mod_php, the same applies to the Apache processes. How to restart cleanly is described in Restarting PHP-FPM and all workers.
Record the result in writing: server, PHP version, package version, CVE in the changelog yes or no, time of the restart. You need this note for management, insurers and a later check for traces.
Interpreting the result
| Finding | Assessment |
|---|---|
| Official version 8.5.12, 8.4.27, 8.3.36 or 8.2.35, processes restarted | PHP2Shell closed |
| Older number, CVE numbers in the package changelog, processes restarted | Backport applied, closed |
| Older number, no changelog entry, no confirmation | unclear, clarify with the provider |
| PHP 8.1 or older without a confirmed backport | open, interim measures and migration needed |
| Processes older than the update | Restart missing, vulnerability still active |
If a server remains in the "unclear" state, treat it like an open one: apply interim measures and keep following up on the clarification until evidence is available. The full version overview is at Which PHP versions are affected?.
How does PHP SOS help?
With the PHP patch service, we take over the check and the proof:
- Find all installations, including secondary versions from hosting panels, Software Collections or containers.
- Assess the package version: official release, backport or open, with evidence from the changelog or from the provider.
- Verify the restart until no process with old code is running any more.
- Create a test record that you can use internally and towards third parties.
Frequently asked questions
Why does php -v show a different version than my website?
Several PHP versions are installed on many servers. The command line uses one of them, the web server or an FPM pool another. So check the version that actually runs in the web context, for example via the FPM binary or the hosting interface.
How do I recognise a backport?
With distribution packages, the fix is often in the package changelog, frequently with the CVE number. On Debian and Ubuntu, apt changelog helps; on RHEL-like systems, rpm -q --changelog. If the entry is missing, clarify the state with the provider.
Can I check the PHP version in the hosting customer menu?
Yes, most interfaces show the configured version per website. Whether a backport has been applied and restarted is usually not visible there. For that, a written confirmation from the hosting provider is the reliable way.