PHP2Shell on Shared Hosting: What Your Host Does and What You Must Check

As of 23 October 2026, the major control panel vendors that shared hosts build on (cPanel, Plesk and CloudLinux) have published fixed PHP packages for PHP2Shell, and several large shared hosts say they have installed them for their customers. If your site is on a shared hosting plan, you cannot patch PHP yourself. Your host does that. Your job is to confirm it happened, run a supported PHP version, and ask about anything the host has not said.

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. The flaw is in PHP itself, not your CMS or plugins. What matters is which PHP build serves your site, and whether PHP was restarted after the update.

Who Patches PHP on Your Plan

Shared hosting means many accounts share one server and one set of PHP installs that the host manages. A VPS (virtual private server) or dedicated server gives you root access, so you manage the software, including PHP. Our guide to hosting types explains the plans in more detail.

Not sure which plan you have? Check your invoice or ask support. The wider split of duties is explained in the shared responsibility model for websites.

Where PHP on a Shared Server Comes From

Shared hosts rarely install PHP straight from php.net. They use packages from their control panel or operating system vendor, and each vendor numbers its fixed builds differently.

cPanel and EasyApache 4 (ea-php)

cPanel servers run PHP packages named ea-php, built through EasyApache 4 (EA4). According to cPanel's news page, "EasyApache 4 25.91 — 2026 October 21" fixes both CVEs "in ea-php74 through ea-php85." The EA4 change log lists ea-php82 to 8.2.35, ea-php83 to 8.3.36, ea-php84 to 8.4.27 and ea-php85 to 8.5.12, and a backport of the fix to ea-php74, ea-php80 and ea-php81. A follow-up release, EA4 25.92, rebuilt the ea-php74, ea-php80 and ea-php81 packages so that their change log lists the CVE backport.

CloudLinux (alt-php, ea-php builds and PHP Selector)

Many shared hosts run CloudLinux, an operating system built for shared servers. It provides its own alt-php packages, which its PHP Selector tool uses to let each account pick a PHP version. It also builds ea-php packages for cPanel servers. CloudLinux's advisory (last updated 23 October 2026, 08:40 UTC) says fixed ea-php packages "for ea-php52 through ea-php85 are in stable," and fixed alt-php packages "are in stable on CloudLinux 7, 8, and 9," with CloudLinux 6 "not confirmed yet."

CloudLinux also warns: "Most of our packages carry the fix as a backport, so their version numbers stay below PHP's: the fixed ea-php84, for example, is 8.4.26-2 and not 8.4.27." CloudLinux released ea-php builds with php.net version numbers on 23 October at 13:10 UTC.

Plesk

Plesk's knowledge base article on PHP2Shell says "all PHP versions shipped with Plesk are also affected." On Plesk for Linux, the fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For the end-of-life branches, Plesk says the fixes for 7.4.33, 8.0.30 and 8.1.34 "have the same version number, but different build date. Versions built on 21 October 2026 have fixes included." Plesk for Windows lists 8.2.35 through 8.5.12, with no fixed builds for older branches. For PHP 5.6, 7.2 and 7.3, Plesk recommends paid TuxCare Extended Lifecycle Support.

DirectAdmin and LiteSpeed

DirectAdmin's staff said in its community forum on 21 October that a new build updates PHP 8.2 through 8.5 and "adds patches for PHP 8.1, PHP 8.0 and PHP 7.4." These are forum posts; the official DirectAdmin changelog had no entry when we checked on 23 October.

Many shared hosts also run LiteSpeed Web Server with its own PHP packages, called lsphp. One detail matters here: in LiteSpeed's documentation, PHP runs in "Detached mode and will not be restarted when LSWS restarts." The host has to restart PHP itself. That is one of the questions in our guide to what to ask your web host.

Why Your Panel Can Show an Old Version After the Fix

You open your panel or WordPress Site Health, see PHP 8.4.26 or 8.5.11, and assume you are exposed. You may not be. Vendors often backport a fix: they copy it into the version they already ship, so the version string stays the same or gets a build suffix. Some examples, as published:

GoDaddy's PHP security update post puts it plainly: "WordPress Site Health won't help here because it shows only the version number. Check the build date instead." You can see the build date in a temporary phpinfo() page, which most hosts let you create, or on the "built:" line of php -v if you have SSH access. Delete any phpinfo() file as soon as you have read it, because it exposes server details. The step-by-step methods are in how to check your PHP version, and the full list of fixed upstream releases is in PHP2Shell fixed versions.

One more caution from hosting.com's PHP2Shell post: "be careful when using php -v as PHP served by the command line can report a different version from the one serving your site." A phpinfo() page loaded through your site shows the PHP that matters.

What Shared Hosts Have Said So Far

These statements are quoted from hosts' own websites, with dates. Status changes quickly, so check the linked page. We list only statements we could read first-hand on 23 October 2026; a host missing here may well have posted one. On VPS and root-access plans, see the plan table above.

Two things to notice. First, the verification method hosts give is the build date, not the version number. Hostinger's status page noted on 22 October that "some websites show PHP version 8.5.11 rather than 8.5.12. This is expected." Second, a statement about "all servers" does not always say which build an end-of-life version such as PHP 7.4 runs. SiteGround, for example, refers in a staff comment to "server-level security mitigations" across all versions in Site Tools, including 7.4. If you are on PHP 8.1 or older, ask your host directly whether a backported build is installed.

Picking a Supported PHP Version in Your Panel

The version you choose still matters. PHP 8.1 and older get no official releases from the PHP project, only vendor backports. Switching branches only helps if the target is a fixed build, so confirm the build afterward. Security support end dates on php.net, as of 23 October 2026:

For most sites, 8.3 or 8.4 is the practical choice. WordPress recommends PHP 8.3 or greater, Drupal 11 supports 8.3 and 8.4, and Joomla 6 recommends 8.4. Treat 8.2 as a stopgap.

cPanel: MultiPHP Manager

cPanel's MultiPHP Manager documentation gives these steps:

1. Open MultiPHP Manager in the Software section of cPanel.
2. Select the checkbox for the domain you want to change.
3. Choose a version from the PHP Version menu. If your host recommends versions, they carry a "Recommended" label.
4. Click Apply.

If a domain shows "Inherited," it uses the server default that the host sets. If the version you want is missing, cPanel says it "is either not installed on the server or is not available for your account," so ask your host.

CloudLinux PHP Selector and Plesk

On CloudLinux servers, hosts often offer PHP Selector instead of, or alongside, MultiPHP Manager. On Plesk, PHP is set per domain in the domain's PHP settings. Menu names vary by host and version, so if you can't find the setting, ask support where it is.

Changing the version can break old plugins and themes, so back up first and test on a staging copy. For older sites, our guide to upgrading an old PHP site safely walks through the order of steps.

Settings You Usually Can't Change Yourself

On 23 October, PHP published an informational advisory for a third issue, CVE-2026-115560. Cloudflare notes that it "affects fully patched PHP releases, including 8.5.12." PHP suggests setting session.upload_progress.enabled=0 "until the next regular bugfix release." PHP also says the setting must go in "php.ini, an FPM pool or server configuration that applies before request parsing," and warns: "Do not rely on ini_set() or FPM .user.ini."

On shared hosting, the settings you control usually load too late for this, so ask your host whether upload progress is off for your account. Hostinger, for example, says it has switched it off on its shared setups. PHP adds that applications which never change the session serializer at runtime "can keep the feature enabled," so this is a precaution, not an emergency. The other temporary measures, and what each one can break, are covered in PHP2Shell interim mitigations.

Imunify360 and Firewalls Are Not the Fix

Many shared hosts run Imunify360, CloudLinux's security suite, which includes a web application firewall (WAF). A WAF filters requests before they reach PHP. CloudLinux is clear about what its rules do: "This is a virtual patch: it stops known request patterns at the server edge while the vulnerable PHP code stays as it is. No rule blocks the out-of-memory path of CVE-2026-109618 yet."

A firewall can reduce attacks while the update rolls out, but it does not replace the patched build. If a host says "we have a firewall rule," ask whether the fixed PHP build is installed too.

If You Run a VPS With cPanel, Plesk or DirectAdmin

With root access, PHP is yours to patch. The vendors' published steps, in outline:

• cPanel on CloudLinux: CloudLinux gives dnf clean all && dnf upgrade "ea-php*" for CloudLinux 8, 9 and 10 (use yum on CloudLinux 7), then /scripts/restartsrv_httpd and /scripts/restartsrv_apache_php_fpm. CloudLinux warns that "security-only update filters in yum and dnf do not list these packages. Use a regular update."
• Plesk: Plesk's call to action is "Update Plesk to the latest available version." To check a version on the command line, Plesk gives this example (replace 8.3 with your version): /opt/plesk/php/8.3/bin/php -v. Look for "built: Oct 21 2026" or later.
• DirectAdmin: staff give da update then da build php, because the PHP rebuild is not automatic unless the CustomBuild cron feature is on.
• LiteSpeed: restarting LiteSpeed does not restart detached PHP. LiteSpeed's documentation gives pkill lsphp or touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt.

Update every PHP version that serves a website, not only the default one. CloudLinux notes that "Hosting servers often run several PHP versions side by side." Then restart PHP. Every setup's restart command is in our guide to restarting PHP workers after a security update.

Your Shared-Hosting Checklist

Conclusion

On shared hosting, PHP2Shell is mostly your host's job, and as of 23 October 2026 the panel vendors have shipped fixed builds and many hosts say they have installed them. What stays with you is short: confirm the build date, not just the version number; move every domain to a supported PHP branch; and get a written answer about any site still on PHP 8.1 or older. If you run your own VPS, or you'd rather have someone check and patch every site for you, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions