How to Patch PHP2Shell on a Plesk Server (Plesk PHP and OS PHP)

The thing that catches people out on Plesk is that "PHP" is not one thing. A Plesk server can offer a customer PHP versions that Plesk itself builds and maintains, and, on the same machine, PHP versions that come straight from the operating system's package repositories. They are updated by different mechanisms. Run only one of the two updates and you have patched half the interpreters, with nothing in the panel to tell you the other half is still exposed. This guide covers both, and assumes Plesk on Linux. For an explanation of the two flaws themselves, see our overview of PHP2Shell, CVE-2026-109618 and CVE-2026-109619.

List every PHP handler on the server

Start by seeing what Plesk thinks is available. The handler list shows each PHP version, whether it is enabled, and where it comes from:

plesk bin php_handler --list

The columns tell you the type and the path. Entries under /opt/plesk/php/ are Plesk-provided builds. Entries pointing at /usr/bin or /usr/sbin, or at packages named like php8.3-fpm or php-fpm, are operating system builds. Note both groups, since each one needs its own update.

Update the Plesk-provided PHP

Plesk published an advisory for these flaws listing the affected and patched PHP builds per branch, and rebuilt the end-of-life branches, 8.1, 8.0 and 7.4, with the fix on 21 October 2026. Updating is done through Plesk's own installer, either from the command line:

plesk installer --select-release-current --upgrade-installed-components

or from the interface under Tools & Settings, then Updates, then Add/Remove Components. The command line is quicker and easier to repeat across several servers. Take a snapshot or backup first if the server is business critical, because the installer upgrades every installed component, not just PHP.

Restart the PHP-FPM services

New packages do not take effect until the running processes are replaced. Plesk runs one FPM service per PHP version, named after the version:

systemctl restart plesk-php83-fpm
systemctl restart plesk-php84-fpm
plesk bin php_handler --reread

Restart the service for each Plesk PHP version you actually have installed, then re-read the handler configuration. A site that runs PHP through FastCGI or Apache's module will pick up the update when the web server restarts, so also restart Apache or nginx during a quiet period.

Update the operating system PHP handlers

OS-vendor PHP is not touched by the Plesk installer. It is updated like any other system package. On Ubuntu or Debian:

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt install --only-upgrade 'php8.3*' 

On AlmaLinux, Rocky or RHEL:

dnf upgrade 'php*'

Adjust the version number to what the handler list showed. Our platform guides give the full details, including how to confirm the fix: Ubuntu and Debian and AlmaLinux, Rocky and RHEL. Restart the matching FPM service afterwards, for example systemctl restart php8.3-fpm.

Check that the fix is actually in

Do not trust the version number on its own. Plesk-built PHP displays the upstream version in the handler list, and a rebuilt end-of-life branch keeps its old number. Compare the build against Plesk's advisory table, and where the package carries a changelog, look for the CVE identifiers:

rpm -q --changelog plesk-php83-cli | grep -E "CVE-2026-10961[89]"

On Debian-based servers, use the package manager's changelog for the same package name where one exists. For operating system handlers, follow the verification step in the platform guide that matches your distribution. If you cannot confirm a build, treat it as unpatched and update it again.

Disable what you do not use

Every PHP version you leave enabled is more surface area and one more thing to remember during the next emergency. In the panel, review which handlers subscriptions actually use, move sites off old versions where the application allows it, and disable the rest. Old branches in particular deserve attention, since they depend on vendors continuing to rebuild them by hand.

Separate Plesk advisories to read

The same Plesk advisory page also lists unrelated issues in its own components, including root-level code execution flaws in the RESTful API and Site Import extensions. These are separate from the PHP bugs and have their own fixes, so read the advisories and apply the extension updates too. A server patched for PHP2Shell but behind on panel updates is still a target. The same principle sits behind our guide to recovering a Plesk admin panel that will not load, where an interrupted update is a frequent cause, so run updates when you can watch them finish.

Look for signs that someone got in first

Updating protects you from here on. It does not tell you what happened before. If the server was exposed for days, check subscriptions for new PHP files in upload folders, unexpected scheduled tasks and unfamiliar outbound connections. Our guide to checking whether PHP2Shell hit your server lists what to look for, and our walkthrough on finding a spammer on a Plesk server is useful if the server has started sending mail it should not.

If you would like this done for you, contact us. Our Plesk server management engineers will update the Plesk and operating system PHP builds, restart the right services, verify the result and check your subscriptions for signs of compromise.