PHP2Shell CVE-2026-109618/109619: patching hosting servers

On 21 October 2026 the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical flaws, nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both score 9.2 under CVSS 4.0 and allow unauthenticated remote code execution. The bugs are in PHP itself, not in WordPress, a plugin, or the control panel, so every shared server you run is in scope. PHP's own advisory says there are no complete mitigations: updating is the only safe choice.

This is for anyone running cPanel, Plesk, or CloudLinux servers with customer PHP sites. The short version: update every PHP build on the box, including the end-of-life ones customers still use, then restart every PHP worker. A package update alone does not replace processes that are already running.

The two CVEs

PHP says the risk is highest for mod_php, where a demonstrated exploit fires before any application code runs. PHP-FPM, php-cgi, and LiteSpeed's lsphp are affected too. watchTowr reports exploitation in its honeypot network since 21 October, and CloudLinux reports a public exploit tool being used for mass scanning.

Fixed builds by platform

Vendor packages carry backported fixes, so the version number is not a reliable check. CloudLinux's patched ea-php84, for example, still reports 8.4.26. Check the package changelog for the CVE IDs instead.

PHP 8.2 reaches end of life on 31 December 2026, so treat this as a good moment to move customers off it.

cPanel and EasyApache 4

yum clean all
yum update "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Confirm the fix landed for each installed version:

rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

To see which domains still run an old PHP you might have forgotten about, whmapi1 php_get_vhost_versions lists every vhost and its version. The PHP handlers comparison explains why a domain on the DSO handler (mod_php) is the one to prioritise.

CloudLinux alt-php

dnf clean all
dnf upgrade 'alt-php*'
rpm -q --changelog alt-php82-common | grep -E 'CVE-2026-(109618|109619)'

On CloudLinux 7 use yum update 'alt-php*'. On CloudLinux 7, 8, and 9, CloudLinux shipped some builds through a temporary php-els repo. Disable it once your packages are current: dnf config-manager --set-disabled php-els (or yum-config-manager --disable php-els on CL 7). Customers selecting old versions in the CloudLinux PHP Selector are covered because alt-php 5.2 to 7.4 were patched too, which is the point of hardened legacy PHP.

Plesk

Update through Tools & Settings › Updates or from the shell:

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

Plesk also fixed its own sw-engine PHP, which runs the panel, in Obsidian 18.0.81 Update 4 and 18.0.80 Update 11. Handlers that use the OS vendor's PHP rather than Plesk's builds update through apt or dnf, not the Plesk installer. plesk bin php_handler --list shows which is which; see Plesk PHP handlers compared.

LiteSpeed: restart lsphp explicitly

LiteSpeed on cPanel runs the same ea-php or alt-php binaries, so the package update covers it. But LSWS runs PHP in detached mode, and a web server restart leaves the old, vulnerable lsphp parents running. Kill them:

pkill lsphp

The gradual restart marker is normally gentler, but it leaves idle accounts on the vulnerable binary until their next hit. Detached mode and lsphp restarts covers the trade-off.

Imunify360 virtual patches

CloudLinux pushed three WAF rulesets on 21 October. 8.83 blocks the public exploit on ModSecurity and Coraza but only logs on LiteSpeed. 8.84 blocks the exploit tool and cross-site upload-progress requests on all web servers, LiteSpeed included. 8.85 adds further tool variants. Check and force the update:

cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION
imunify360-agent update --force modsec-rules

8.84 can break legitimate cross-domain upload forms. More importantly, no rule blocks the CVE-2026-109618 out-of-memory path. As with any Imunify360 virtual patch, this buys time. It does not fix PHP.

Interim mitigations if you can't patch today

From PHP's advisory. Set these in the global php.ini, an FPM pool, or server config, then restart every worker. ini_set() and FPM .user.ini files are applied too late to help.

session.upload_progress.enabled=0
fatal_error_backtraces=0   ; PHP 8.5 only
memory_limit=-1
post_max_size = 32M        ; 8M if the site takes no uploads

The first two target CVE-2026-109619. memory_limit=-1 narrows CVE-2026-109618, but on shared hosting it removes per-account memory protection, so you are relying on CloudLinux LVE limits or cgroups to contain runaway scripts. Do not substitute RLIMIT_AS or RLIMIT_DATA: PHP warns they can trigger the vulnerable allocation failure.

Patched packages reach you through active vendor channels. A server with a lapsed cPanel license or CloudLinux license stops receiving them.

Next steps

• Add or update a PHP version in EasyApache 4 if an update stalls at Review.
• MultiPHP Manager vs CloudLinux PHP Selector to decide which PHP stack to standardise on.
• Imunify360 malware cleanup workflow if an unpatched server shows signs of compromise.