PHP2Shell on cPanel: EasyApache 4 Updates and MultiPHP

As of 23 October 2026, cPanel has shipped fixed PHP for PHP2Shell in two places: EasyApache 4 25.91, which fixes the flaws "in ea-php74 through ea-php85," and an update to the internal PHP that runs cPanel and WHM themselves. Exploitation attempts are widely reported, confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: if you run your own cPanel and WHM server, you have three jobs. Install the fixed ea-php packages, make sure cPanel itself is on a build that carries the internal PHP fix, then restart Apache and PHP-FPM and check what your sites actually run. If you have a cPanel account on someone else's server, such as shared or reseller hosting, the server owner does this. Our guide to PHP2Shell on shared hosting covers what to check from your side.

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. This guide covers cPanel servers only: which packages carry the fix, how to update and restart, how to confirm it worked, and what to do about old PHP versions.

Two Copies of PHP on Every cPanel Server

The PHP that runs your websites and the PHP that runs cPanel are different software, and each needs its own fix. Websites run ea-php packages built through EasyApache 4 (EA4), cPanel's system for building Apache and PHP. On CloudLinux servers, sites may instead run alt-php packages chosen through PHP Selector. The cPanel, WHM and webmail screens run on cPanel's internal PHP. cPanel's 21 October notice on its news page says the internal update "affects PHP in cPanel interfaces, including Roundcube webmail."

Updating ea-php does not update the internal copy, and updating cPanel does not update ea-php. Here is what carries the fix, as of 23 October 2026:

The WP Toolkit line comes from the Plesk change log, which also lists WP Toolkit releases for cPanel.

What EasyApache 4 25.91 and 25.92 Changed

The EA4 change log lists the 25.91 entries one package at a time: "Update ea-php82 from v8.2.34 to v8.2.35," "Update ea-php83 from v8.3.35 to v8.3.36," "Update ea-php84 from v8.4.26 to v8.4.27" and "Update ea-php85 from v8.5.11 to v8.5.12." For the three end-of-life branches it says "Backport the fix for CVE-2026-109618 and CVE-2026-109619 to ea-php74," with matching entries for ea-php80 and ea-php81.

A backport means cPanel copied the fix into the version it already ships. The version number stays the same: ea-php74 still reports 7.4.33, ea-php80 still reports 8.0.30, and ea-php81 still reports 8.1.34. That is why EA4 25.92, also dated 21 October, "rebuilds the ea-php74, ea-php80 and ea-php81 meta packages so their change log lists the CVE-2026-109618 and CVE-2026-109619 backport." After 25.92, you can prove the fix by reading the package changelog, which we cover below.

One more detail for CloudLinux servers. CloudLinux builds its own ea-php packages for cPanel, and its first fixed builds kept older numbers. Its advisory gives the example that "the fixed ea-php84, for example, is 8.4.26-2 and not 8.4.27." CloudLinux then released ea-php builds with php.net version numbers on 23 October at 13:10 UTC. On CloudLinux, check the changelog, not just the number.

Is Your cPanel Version Still Getting Fixes?

The internal PHP fix only reaches cPanel versions that cPanel still builds. Its product versions page (last modified 2 October 2026) lists these end-of-life dates:

cPanel's rule is plain: "Unsupported versions don't receive security updates or bug fixes." cPanel did ship 136.0.50 with the fix, even though its own table shows 136 past end of life. Don't count on that happening again. If you are on 136, move to 138 or to 134 LTS. If you are on 110 LTS, its end of life is December 2026, so plan that move now too. Compare your build number with the table. A server older than these builds does not have the internal fix.

How the Update Reaches Your Server

cPanel's update preferences documentation says: "By default, the system will apply available security updates for your current major version every hour via a cron job. This cron job runs even if you disable version or package updates or set them to run manually." There is an exception: "The cron job takes no action if you disable the update repository or set the server to use a specific numbered version." If you pinned your server to a numbered version, it is not getting these updates.

The docs don't say whether that hourly job also installs the EA4 ea-php packages. Don't assume it did. Update by hand, in this order:

1. Take a backup or a server snapshot first. Our guide to backups and recovery explains what a usable backup includes.
2. Update cPanel and WHM. cPanel's docs say "The /usr/local/cpanel/scripts/upcp script lets you update cPanel & WHM on the command line." Run /usr/local/cpanel/scripts/upcp as root.
3. Update the ea-php packages. In WHM, open System Update: "Click Proceed. All RPM packages will update." On CloudLinux 8, 9 and 10, CloudLinux gives the command dnf clean all && dnf upgrade "ea-php*" (use yum on CloudLinux 7).
4. Update every installed PHP version, not just the default. CloudLinux puts it this way: "Hosting servers often run several PHP versions side by side, so update each one that serves websites."
5. Restart Apache and PHP-FPM (next section), then verify (the section after that).

CloudLinux adds a warning that catches people who use security-only update filters: "Security advisory metadata (OVAL and UpdateInfo) is not published yet, so security-only update filters in yum and dnf do not list these packages. Use a regular update."

Restart Apache and PHP-FPM

A fixed package on disk does nothing until the PHP processes that serve your sites restart. cPanel's restartsrv script covers both services. CloudLinux's advisory gives these two commands:

/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

The first restarts Apache. cPanel's docs describe the second service as "The Apache PHP-FPM service." The script also accepts options such as --graceful and --hard. If any site runs PHP as an Apache module (mod_php), use a full restart rather than a graceful one. Apache's documentation doesn't say whether a graceful restart loads an updated PHP module, and every vendor's instructions use a full restart. WHM also has a Restart Services screen if you prefer the interface.

If the server runs LiteSpeed Web Server, there is one more step. cPanel's MultiPHP Manager for WHM says that with an active LiteSpeed installation, "The system will set your PHP handler settings to lsphp." LiteSpeed still uses your ea-php or alt-php builds, but its PHP runs in "Detached mode and will not be restarted when LSWS restarts." LiteSpeed's documentation gives pkill lsphp or touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt, or the "Restart Detached PHP Processes" button in its cPanel plugin. Every restart method, by server type, is in our guide to restarting PHP workers after a security update.

How to Verify the Fix

Check each PHP version that serves a site, the way that version was fixed:

To read a changelog, CloudLinux gives this pattern: rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'. Replace 84 with the version you are checking, such as 74 or 81. If the command prints lines naming both CVEs, that build has the fix.

Then check what your websites actually run. In cPanel, MultiPHP Manager shows "The PHP version that the domain currently uses," including domains marked as inherited. That tells you which ea-php package to check, but not whether the running processes restarted. For that, load a temporary phpinfo() page through the site, read the version and build date, then delete the file. Don't rely on php -v alone: the command-line PHP can be a different version from the one serving your sites. Our guide on how to check your PHP version walks through each method, and the PHP2Shell version lookup tells you whether a given build is fixed.

CloudLinux alt-php and PHP Selector

Many cPanel servers run CloudLinux, an operating system built for shared servers. Its alt-php packages sit alongside ea-php, and PHP Selector lets each account pick one. CloudLinux's advisory, last updated 23 October 2026, says alt-php fixes "are in stable on CloudLinux 7, 8, and 9," while "CloudLinux 6 is not confirmed yet."

On CloudLinux 8 and 9, the fixed alt-php numbers now match php.net: "alt-php82 8.2.35-1, alt-php83 8.3.36-1, alt-php84 8.4.27-1, and alt-php85 8.5.12-1." CloudLinux adds that "Earlier fixed builds, such as alt-php85 8.5.11-5, are already protected." To confirm, it gives rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'. After a regular update, restart Apache, PHP-FPM or LiteSpeed, as above.

If you also run Imunify360, know what it is. CloudLinux calls its PHP2Shell rules "a virtual patch: it stops known request patterns at the server edge while the vulnerable PHP code stays as it is." It adds: "No rule blocks the out-of-memory path of CVE-2026-109618 yet." The package update is the fix.

Old PHP Versions on cPanel

cPanel's MultiPHP docs say "EasyApache 4 supports PHP version 7.4 and PHP 8.1 through 8.5." The PHP project itself no longer releases 8.1 or older: 8.1 reached end of life on 31 December 2025, 8.0 on 26 November 2023 and 7.4 on 28 November 2022. cPanel's backported ea-php74, ea-php80 and ea-php81 builds close PHP2Shell, but they are a stopgap. Even PHP 8.2 reaches end of life on 31 December 2026, so 8.3 or newer is the better target.

For anything older than 7.4, cPanel's WHM documentation points elsewhere: "If you require legacy PHP versions like 5.6 or 7.x, you can use TuxCare Extended Lifecycle Support (ELS) from CloudLinux." CloudLinux says its own ea-php builds are fixed for "ea-php52 through ea-php85."

To move a domain to a newer version, use MultiPHP Manager. cPanel's steps: "Select the checkbox for the domain that you wish to change. Select the desired version of PHP from the PHP Version menu," then "Click Apply." Test the site on a staging copy first if you can. In WHM, the System Settings tab sets the server default, but cPanel notes that changes there "will not change existing accounts' configurations unless you set those accounts to inherit global settings." Check existing accounts one by one. Our guide to upgrading old PHP safely covers testing and rollback.

Upload Progress and Other Settings

On 23 October, PHP published an informational advisory for a third issue, CVE-2026-115560. It affects patched releases too. PHP suggests you "set session.upload_progress.enabled=0 until the next regular bugfix release." It also says applications that never change the session serializer at runtime "can keep the feature enabled," so this is a precaution, not an emergency.

Where you set it matters. PHP's advisory says to use "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 a cPanel server, that means the php.ini for each ea-php version, or the PHP-FPM pool settings, followed by a restart. Settings an account owner adds in a .user.ini file or in application code do not count. The other temporary measures, and what each can break, are in PHP2Shell interim mitigations.

Conclusion

On cPanel, PHP2Shell is fixed in packages, not in a new panel feature, and there are two sets of packages to check: ea-php for your sites and the internal PHP inside cPanel itself. Run upcp and a full system update, restart Apache, PHP-FPM and any detached LiteSpeed PHP, then confirm each version by number or changelog through a real web request. Move sites off PHP 8.1 and older while you're at it, and get off cPanel versions past end of life. If you'd rather have someone patch and verify the server for you, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions