PHP2Shell on cPanel: find and update PHP per domain

On cPanel, PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is fixed by an updated PHP package installed on the server, and a setting in your account cannot do that. Account holders can see each domain's PHP branch in MultiPHP Manager or Select PHP Version, then ask the host for the fixed build and a worker restart. Server owners update the EasyApache packages and restart PHP-FPM.

The bug is in the PHP engine, so WordPress or plugin updates do not close it. The wider explanation is in the plain-language write-up of the flaw, and the tracker holds the rest of this week's incidents. Other panel problems are collected in the other hosting panel guides, and the earlier cPanel and WHM flaw has its own host questions.

Which PHP does each of my cPanel domains use?

A cPanel server can run several PHP versions side by side, and each domain is assigned to one. Two tools show the assignment, and which one you have depends on the host.

• MultiPHP Manager lists each domain, its PHP version, an "Inherited" label when it follows the system default, and whether PHP-FPM is on, per cPanel's documentation. Bluehost describes the same screen under Software in cPanel in its help article.
• Select PHP Version is the icon label for CloudLinux's PHP Selector. Namecheap's guide shows it on a shared cPanel server, and it also lets an addon domain run a different version from the account.

Check every domain, including addon domains and subdomains. A domain you pinned to an old version years ago keeps that version after the host updates its default.

Neither screen tells you the build. Both show a branch such as 8.3. The WordPress Site Health page (Tools, Site Health, Info, Server), which GoDaddy points to, shows a version string, and on a backported package that string keeps its old number.

Can I update PHP myself from cPanel?

On shared hosting, no. The version picker only lists versions installed on the server and available to your account, per cPanel's documentation. Choosing 8.4 moves your domain to the 8.4 package the host installed. It installs nothing.

That gives you two jobs. First, make sure no domain is pinned to a branch the host has stopped updating. Second, get the host to confirm the build that serves the domain. If the host has patched, moving a domain from 7.4, 8.0 or 8.1 to a tested 8.4 or 8.5 is a sound step, because cPanel marked ea-php74, ea-php80 and ea-php81 end of life on 29 April 2026 according to its change log.

Back up first and test the site. Old plugins and themes are what usually break on a newer branch.

What do I ask my cPanel host?

Send this for your own domain and keep the reply:

For [your domain], which PHP package or build serves web requests, and does it include the fixes for CVE-2026-109618 and CVE-2026-109619? On cPanel, is that an ea-php package or a CloudLinux alt-php package, and which version of it is installed? At what date and time were Apache, PHP-FPM or LiteSpeed workers restarted after the install? Do I need to change anything on my side?

The ea-php versus alt-php part matters because the two are updated separately, as the server section below shows. The longer template and a table of what each reply means is in the email template and reply guide.

What have cPanel hosts said? (checked 24 October 2026)

This table records each host's own statement and dates it. A host statement is not proof for your account. Statements are the hosts' own and were not independently verified.

For hosts not in this table, see the shared-hosting page. A host with no dated statement is Unknown, which does not mean unpatched.

How does a server owner update every PHP on cPanel?

This section is for people with root on a cPanel server. Take a backup or snapshot first.

Which PHP packages can a cPanel server have?

A server can carry four kinds of PHP, and each updates on its own path.

Updating one does nothing for the others. A server where every ea-php package is fixed can still serve an account from an old alt-php build.

What did cPanel change in each ea-php package?

On the backported branches the meta packages were rebuilt the same day so their change logs name both CVEs. CloudLinux's own ea-php builds are a separate case. Its early fixed builds, such as ea-php84 8.4.26-2, kept lower numbers, and builds carrying php.net numbers followed on 23 October. A scanner reading the number can flag a patched server for that reason.

How do I install the updates and restart the workers?

In WHM, EasyApache 4 links to the System Update page that installs package updates, as the EasyApache documentation describes. From a shell, CloudLinux gives these commands:

dnf clean all && dnf upgrade "ea-php*"
dnf clean all && dnf upgrade "alt-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Use yum on CloudLinux 7. CloudLinux notes that its security advisory metadata was not published yet at its 23 October update, so security-only update filters do not list these packages. Run the plain update. If an update stalls, update cloudlinux-release first, as its post describes.

cPanel documents the PHP-FPM restart target as /usr/local/cpanel/scripts/restartsrv apache_php_fpm. On LiteSpeed, WHM's MultiPHP Manager cannot edit settings and the handler is lsphp, so restart LiteSpeed through its own control.

To see every domain's assignment, open WHM MultiPHP Manager and its User Domain Settings tab.

How do I confirm the fix is installed and running?

• Package fixed. Run rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)', once per branch you run. CloudLinux gives the same check for alt-php, with alt-php85-common.
• Workers restarted. The Apache and PHP-FPM start times (see how to prove a restart ran) must be later than the package install time (rpm -q --last shows the install time).
• Each domain on a fixed branch. Read the assignment in MultiPHP Manager, and for CloudLinux accounts read the Selector setting too.
• Record it. Keep the changelog output and the start times with the date.

CloudLinux warns that the native PHP packages for some streams do not list CVE ids in their changelogs. For those it says to check that the version is 8.2.35 or 8.3.36 or later.

Does a firewall rule or setting replace the update?

No. CloudLinux said at its 23 October update that no Imunify360 rule blocked the out-of-memory path of CVE-2026-109618 yet, and PHP says updating is the only complete fix. PHP's interim settings are memory_limit=-1 set so no pool restores a limit, a low post_max_size, and session.upload_progress.enabled=0 for CVE-2026-109619, followed by a restart of every worker. PHP lists these as no substitute for updating.

Set that last option in php.ini, the pool or server configuration. PHP says not to rely on ini_set() or .user.ini, which is why an account-level change on shared hosting is the wrong lever.

PHP's 23 October informational advisory adds a third identifier, CVE-2026-115560, tied to session upload progress under an unusual session handler setup. PHP says it will publish a full advisory with the next regular release and recommends the same session.upload_progress.enabled=0 setting. Hostinger's page mentions it on 23 October at 12:53 UTC. No new PHP version had been announced at our check on 24 October 2026.

Am I affected? A three-state self-test

What if my PHP is end of life, and did anything get in first?

cPanel and CloudLinux backports cover the old branches for now, and the PHP project's notice says 8.1 and older receive no project updates. Treat a backport as a bridge. PHP 8.2 security support ends on 31 December 2026 on its supported versions page, so plan the move to 8.4 or 8.5. What changes on PHP 8.1 and older is on its own page.

Patching removes the hole and leaves anything planted earlier. AWS reported honeypot attempts from 17 October, and says it is unclear whether the early ones would have worked on real systems. If your server was unpatched and reachable, look for PHP files you did not upload, cron entries you did not create and unknown admin accounts, and follow the 10-minute response. If you run Plesk instead, checking the PHP handler per domain works differently. The runtime patch guide covers the other platforms, and who handles patching on each hosting type explains the shared versus server split.

The free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup, and it cannot see a backport or a restart.