# Plesk Server: Checking and Patching PHP Versions > Plesk PHP update after PHP2Shell: how to check handlers, package state and backports, restart all PHP-FPM services and document the patch cleanly. Source: https://phpsos.de/en/server/plesk/ 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:** A Plesk PHP update is only complete when every installed PHP version is on a fixed release, all PHP-FPM services have been restarted, and you can prove this with the package state and the process start times. The version number shown in the panel is not enough on its own, because backports often leave it unchanged. ## What PHP2Shell means on Plesk servers PHP2Shell refers to two critical vulnerabilities in PHP itself (CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2). They allow attackers to execute code on the server without logging in. Among those affected are PHP-FPM and Apache with mod_php, which are exactly the operating modes Plesk sets up for websites. On 21 October 2026 the PHP project released the fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no more official updates for PHP 8.1 and older. Plesk servers have one peculiarity: several PHP versions often run side by side, some provided by Plesk itself, some by the operating system. Each of them needs its own check. > **Important:** > An update in the panel replaces files on disk. As long as old PHP processes keep running in memory, the vulnerability stays open. Without a restart of all workers, the patch is not effective. ## Plesk PHP update: record the inventory first Before you update anything, get a list of all PHP handlers and the domains that use them. You can do this in the panel (Tools & Settings, PHP Settings) or on the command line. The following commands change nothing; they only read. ```bash # All registered PHP handlers with version and path plesk bin php_handler --list # Version of every PHP version installed by Plesk (path as an example) for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done ``` For each handler, note the version, the operating mode (FPM, FastCGI, Apache module) and the number of domains. Handlers without a domain are no all-clear. They can be assigned later or run on test subdomains. ## Check the package state, not the display Plesk shows the version number that PHP itself reports. If Plesk or the distribution ships the fix as a backport, it may still say 8.2.34 although the correction is included. Conversely, a number that looks current can be misleading if a package has not been updated yet. What matters is the installed package state and the vendor's written confirmation. ```bash # Debian/Ubuntu (package names as an example) dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)' # AlmaLinux/Rocky/RHEL (package names as an example) rpm -qa | grep -E 'plesk-php|^php' | sort ``` Compare the package versions with the information in the Plesk changelogs and the notes from your distribution. If it is not clearly documented there that CVE-2026-109618 and CVE-2026-109619 are fixed, ask the vendor. You will find a template for that under [Asking your host for the patch status](https://phpsos.de/en/ratgeber/hoster-patch-status-erfragen/). ## Apply the update and restart all workers The update itself runs through the Plesk installer or the system's package manager. After that comes the step that is missed most often: the restart. Under Plesk, every PHP version has its own FPM service. Restart all of them, not only the one for the main domain. ```bash # List all PHP-FPM services (service names as an example) systemctl list-units --type=service | grep -i 'php.*fpm' # Restart each service, for example: systemctl restart plesk-php84-fpm # Check the start time of the running PHP processes ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep ``` If a domain runs with Apache and mod_php, restart Apache completely. If the start time of a PHP process is before the update, it has not been renewed yet. More on this step under [Restarting PHP-FPM and all workers](https://phpsos.de/en/php2shell/php-fpm-neustart/). ## Interim protection while the update is still missing If no patch is available yet for a version, php.net recommends interim measures. They are not complete protection. Under Plesk, you set values that applications must not override as `php_admin_value` in the domain's additional FPM directives, or server-wide in the php.ini of the respective version. ```ini ; Example of additional PHP-FPM directives in Plesk php_admin_value[session.upload_progress.enabled] = 0 php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 6M ``` For uploads, php.net provides `post_max_size = 32M`, with `upload_max_filesize` below it. On PHP 8.5, `fatal_error_backtraces=0` is added. The memory limit via `memory_limit=-1` should only be used together with a limit at container or cgroup level. Afterwards, all workers are restarted again. Details are under [Immediate measures without a patch](https://phpsos.de/en/php2shell/sofortmassnahmen-ohne-patch/). The BSI recommends taking web servers off the network temporarily if the update is not possible immediately. ## After the patch: preserve logs and look for traces A patch closes the vulnerability for the future. It does not remove malware that was planted earlier, and it does not prove that nothing happened. So keep the web server logs from 20 October 2026 onward. Plesk stores them per domain under the `logs` directory; do not shorten the retention period in this situation. Watch for new or modified PHP files in upload directories, unknown scheduled tasks and new administrator accounts. So far there are no published, confirmed indicators of compromise; detection relies on behavioral analysis. If you find anything unusual, do not carry on alone; preserve the state first. ## How does PHP SOS help? - We record all PHP handlers on your Plesk server, assign domains to them and check the actual package state for each version. - As part of our [PHP patch service](https://phpsos.de/en/leistungen/php-patch-service/), we apply updates, restart all services and document process start times as evidence. - Where a patch is missing, we set the interim measures according to php.net server-wide and in a way that cannot be overridden. - We preserve logs and look for traces of a compromise, and if we find any, continue with [incident response](https://phpsos.de/en/leistungen/incident-response/). - Afterwards, we harden the server permanently and remove PHP versions you do not need. ## Frequently asked questions **Why does Plesk still show PHP 8.2.34 after the update?** Distributions and vendors sometimes apply security fixes as a backport without changing the version number. In that case the package state and the vendor's confirmation are what counts. The display alone proves neither a patch nor its absence. **Is it enough to click Update in the Plesk panel?** The update puts new files in place, but the running PHP processes keep working with the old code in memory. The new state is only active after all PHP-FPM services and the web server have been restarted. Afterwards, check the start time of the processes. **Do I also have to patch PHP versions that no domain uses?** Yes, as long as they stay installed. An unused handler can be assigned by accident later or be reachable through test environments. It is better to uninstall versions you do not need completely. **Does a WordPress update in the Plesk toolkit help against PHP2Shell?** No. PHP2Shell affects PHP itself, not the CMS. A CMS update is still worthwhile, but it does not close this vulnerability. ## Sources - [php.net: Security announcements](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [php.net: Supported versions](https://www.php.net/supported-versions.php) - [BSI (German Federal Office for Information Security)](https://www.bsi.bund.de/)