# Multiple PHP Versions on One Server: Patch Each One Separately > Multiple PHP versions on one server: find every installation, clarify origin and responsibility, patch each one separately, restart it and document the proof. Source: https://phpsos.de/en/blog/mehrere-php-versionen-server/ As of: 25/10/2026 Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **In short:** If several PHP versions run on a server, each one must be checked, updated and restarted separately after PHP2Shell. Typical sources are the operating system, hosting panels such as Plesk or cPanel, third-party sources such as sury.org or Remi, CloudLinux, LiteSpeed and self-compiled versions. Only a complete list built from packages, files and running processes shows whether no version was really overlooked. ## The forgotten version A server that has been running for a few years collects PHP versions the way an attic collects old furniture. The panel brought three branches, an older version from a third-party source was added for one customer, and the operating system has its own. Each of them was installed once for a good reason. Only today nobody remembers which ones are still needed. After PHP2Shell, that is exactly a problem. The fixes appeared on 21 October 2026 for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. But each installation on the server receives them in its own way, from its own package maintainer and at its own time. For PHP 8.1 and older, there are only minimal source backports. Anyone who updates only the main version leaves the others open. ## Where the many versions come from The overview below lists typical sources and example paths. The exact paths differ by version and distribution. | Source | Example path | Who supplies the patch | |---|---|---| | Operating system Debian/Ubuntu | `/usr/bin/php8.3`, `/etc/php/8.3/` | Distribution | | Operating system RHEL family | `/usr/bin/php`, `/etc/php-fpm.d/` | Distribution | | Plesk | `/opt/plesk/php/8.3/` | Plesk | | cPanel (EasyApache 4) | `/opt/cpanel/ea-php83/` | cPanel | | CloudLinux alt-php | `/opt/alt/php83/` | CloudLinux | | Remi Software Collection | `/opt/remi/php83/` | Remi | | sury.org | `/usr/bin/php8.3` as with the system | sury.org | | LiteSpeed | `/usr/local/lsws/lsphp83/` | LiteSpeed or package source | | Self-compiled | often `/usr/local/bin/php` | You yourself | | Container | inside the image | Image publisher, rebuild by you | Packages from sury.org are especially tricky because they use the same paths as the distribution. Whether a `php8.3` comes from Debian or from sury.org is shown only by the package source. The particulars are described in the articles [The sury.org repository](https://phpsos.de/en/blog/sury-repository-php/) and [The Remi repository](https://phpsos.de/en/blog/remi-repository-php/). How Plesk manages its versions is described on the page [Plesk servers: checking and patching PHP versions](https://phpsos.de/en/server/plesk/). ## Finding all PHP installations A reliable list comes from three perspectives. The commands are read-only and may run for some time depending on the server. ```bash # 1. Packages: what the package manager knows dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp" rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort # 2. Files: executable PHP binaries, also outside the package manager find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null # 3. Processes: what is really running right now, with start time ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp" ``` Compare the three lists. A file without a package points to a self-compiled or manually copied version. A process without a matching file can indicate a deleted but still running installation. With Apache, also check whether a PHP module is loaded, for example with `apache2ctl -M` or `httpd -M`. Containers and Kubernetes pods appear in these lists only partially and need a separate check of the images. ## Patching each version separately Once every installation has a line in your list, the same procedure follows for each: 1. **Clarify responsibility:** does the patch come from the distribution, the panel, a third-party source or from you? 2. **Assess the status:** official fixed version, confirmed backport, unclear or open. 3. **Update:** via the route of the respective source, not via another one. 4. **Restart:** the service of this version, not just the main service. With mod_php, the web server. Details are at [Restarting PHP-FPM and all workers](https://phpsos.de/en/php2shell/php-fpm-neustart/). 5. **Verify:** compare the process start time with the update time. 6. **Document:** version, package status, proof, restart time. For versions for which there is no patch, the interim measures from php.net apply until migration. Set these separately for each version, because each installation has its own php.ini and its own pools. > **Important:** > Do not forget the command line. Cron jobs and scripts often run with a different PHP version than the website. This version, too, must be at a fixed status, even if it processes no web requests. ## Which version does the command line use, and which does the container? Two areas fall through the net especially often. The first is the command line. On Debian and Ubuntu, the alternatives system decides which binary sits behind the `php` command. `update-alternatives --display php` shows which versions are registered and which one currently applies. Cron jobs that call a fixed path such as `/usr/bin/php7.4`, however, bypass this setting. That is why it is worth looking at the crontabs of all users and at the configuration of panels that create their own cron jobs. The second area is containers. A Docker container on the server brings its own PHP version, which appears in no package list of the host. `docker ps` shows running containers; whether PHP is inside and in which version is revealed by a look into the image or a `php -v` in the container. The patch there is not applied on the host but by rebuilding the image and replacing the container. ## Fewer is safer The best check is the one you do not have to make. Every installed PHP version doubles the effort at the next vulnerability. After PHP2Shell, a clear rule is therefore worthwhile: every version on the server needs a purpose and an owner. What has neither is first deactivated and, after an observation period, removed. More in the article [Switching off old PHP versions in the hosting panel](https://phpsos.de/en/blog/alte-php-versionen-abschalten/). ## How does PHP SOS help? - We create a complete list of all PHP installations on your servers from packages, files, processes and containers. - For each version, we clarify origin, responsibility and patch status. - Within the [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we update every version, restart every service and document the status. - Together with you, we decide which versions stay, and we remove the rest in a controlled way. ## Frequently asked questions **Why are several PHP versions running on my server?** Common reasons are hosting panels that bring their own PHP builds, third-party sources such as sury.org or Remi for newer versions, and older applications that need a particular version. Often the operating system's own PHP version is there as well. **Is a PHP version dangerous if no website uses it?** As long as it is installed and active as a service, it may be reachable, for example via a test domain, a forgotten pool or a cron job. It can also later be assigned to a website by mistake. You should remove versions you do not need. **How do I find all PHP installations on a Linux server?** Combine three perspectives: installed packages, executable PHP files in the file system, and running processes. Only when all three give the same picture is the list complete. **Do I have to restart each version separately after the update?** Yes. Each version usually has its own FPM service, LiteSpeed has its own lsphp processes, and mod_php lives inside the Apache process. Restarting the main service does not renew the others. ## Sources - [php.net: Security announcements](https://www.php.net/) - [php.net: Supported versions](https://www.php.net/supported-versions.php) - [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)