A cPanel server is the awkward case for PHP2Shell, because it almost never runs a single PHP. EasyApache 4 installs a separate build for every version you enabled, CloudLinux adds its own alternative builds on top, and every account can be pinned to a different one in MultiPHP Manager. A server where you updated "PHP" and moved on can still have a dozen vulnerable interpreters answering requests. This guide goes through the update in a sensible order and ends with a check that proves the fix is present. If you want the background on the two flaws first, our overview of PHP2Shell, CVE-2026-109618 and CVE-2026-109619 covers it.
See which PHP versions the server actually uses
Open WHM and go to MultiPHP Manager to see the system default and the version each domain is assigned. Then list the installed builds from the shell:
ls -d /opt/cpanel/ea-php*
rpm -qa | grep -E "^ea-php[0-9]+-php-cli"
Write down every version you see. The default is rarely the only one in use, and old versions tend to stay installed because one customer's site needed them years ago.
Update the EasyApache PHP packages
On a CloudLinux server, CloudLinux has published fixed ea-php packages for EasyApache 4 covering the whole range from ea-php52 through ea-php85, delivered through the normal stable repository with no special repository needed, according to its advisory for this issue. Update all of them in one pass:
dnf clean all
dnf update 'ea-php*' 'ea-apache24*'
On older CloudLinux 7 or CentOS 7 systems that still use yum, the equivalent is yum clean all && yum update 'ea-php*' -y. Do not limit the update to a security-only filter. The CloudLinux notes point out that --security style listings may not show these updates, so a normal full update is what you want.
If the update reports nothing to do on a CloudLinux machine, the EasyApache repository may be disabled. Enabling it with dnf config-manager --set-enabled cl-ea4 and trying again is the documented fix.
Update the CloudLinux alternative PHP builds
If CloudLinux's PHP Selector is in use, customers may be running the alt-php builds instead of the EasyApache ones, and those are separate packages:
dnf update 'alt-php*'
for p in /opt/alt/php*/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
Accounts on the native selector option use the EasyApache build, so both sets need updating. Missing the alt-php side is an easy mistake because it is invisible in WHM.
Servers without CloudLinux
On standard cPanel, EasyApache packages come from cPanel's own repository, and the timing of the rebuilt packages can differ from CloudLinux. Do not assume they have landed. Run the same update command, then check the package changelog before deciding you are done. If the CVE is not mentioned, the fix is not in yet, so look at the EasyApache 4 changelog in WHM and update again later in the day. This is exactly the situation where the version number cannot help you, since a patched build can carry the same number as a vulnerable one.
Restart PHP and the web server
Updated packages do nothing until the processes that run PHP restart. On cPanel:
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm
If the server runs LiteSpeed rather than Apache, restart it as well:
/usr/local/lsws/bin/lswsctrl restart
Do this when a short interruption is acceptable, and remember that long-running PHP scripts, queue workers and cron jobs started before the update are still running the old code. Restart those too.
Prove the fix is present
Look in the changelog of each installed build for the CVE identifiers. A single loop covers every version:
for p in $(rpm -qa | grep -E "^ea-php[0-9]+-php-cli"); do
echo "== $p"; rpm -q --changelog "$p" | grep -E "CVE-2026-10961[89]" | head -2
done
A build that prints the CVE lines includes the fix. A build that prints nothing does not, and needs another update or removal. For the alt-php builds, run the same rpm -q --changelog check on the corresponding alt-php packages. Fixed CloudLinux builds also carry a release suffix, so the full package name is more informative than the version printed by php -v.
Handle end-of-life versions deliberately
PHP 8.1, 8.0 and 7.4 no longer receive official releases from the PHP project. CloudLinux has said it backported the fix into the supported alt-php and ea-php branches, including these older ones, which is a relief for customers who cannot upgrade yet. It is still a temporary position, not a plan. Each old version you keep is another interpreter to track and another reason a future flaw will catch you out. Use MultiPHP Manager to find the accounts still on old versions, test their sites on a current version such as 8.3 or 8.4, and move them. WordPress sites are usually the easy ones, as covered in our guide to optimising WordPress on a cPanel server.
Imunify360 and ModSecurity
If the server runs Imunify360 or a ModSecurity rule set, make sure it is updated. Rules added after the disclosure can block known attack requests and reduce your exposure while you work. Treat this as a second layer, because it blocks patterns and does not remove the flaw from PHP. Update first, rely on the rules second.
Watch for what the update does not tell you
Patching closes the door but does not tell you whether someone already came through. Exploitation attempts were reported before the public announcement, so on a server that was unpatched for several days, check for new PHP files, unfamiliar processes and unexpected cron jobs. Our guide to checking whether PHP2Shell hit your server lists what to look for. cPanel servers also have a history of getting hit hard when a vulnerability goes unpatched, which is why a clear patching routine, like the one in our server maintenance checklist, is worth having in place before the next one.
If you would rather hand this over, contact us. Our cPanel server management engineers will update every EasyApache and CloudLinux PHP version on your server, restart the right services, verify each build against its changelog and check your accounts for signs of compromise.
Need your cPanel server patched today?
Our cPanel engineers update every EasyApache and CloudLinux PHP version, restart services, verify the fix and check accounts for compromise.



