In short: A cPanel PHP update after PHP2Shell has three steps: bring all ea-php packages and, where applicable, alt-php packages to a fixed release, restart PHP-FPM and Apache completely, and document the package state. Customers on the server cannot set the most important interim values themselves; the WHM administrator has to do it.
Starting point on cPanel servers
PHP2Shell covers the vulnerabilities CVE-2026-109618 and CVE-2026-109619 in PHP itself. Both allow malicious code to be executed without logging in and are rated CVSS v4.0 9.2. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are affected. On 21 October 2026 the PHP project released the versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
cPanel does not ship PHP as a single package but through EasyApache 4, with one package set per version, such as ea-php83 or ea-php84. On some servers, the operating system's own packages are added, and on CloudLinux the alt-php versions. Each source has its own state. You only get a complete picture when you check all three.
cPanel PHP update: check inventory and assignment
Start with an inventory. The following commands only read and change nothing. Paths and package names are examples and may differ depending on the installation.
# PHP versions installed according to the WHM API
whmapi1 php_get_installed_versions
# Version of each ea-php installation
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done
# Package state (RPM-based systems, example)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort
In the MultiPHP Manager you can see which domain uses which version and whether PHP-FPM is enabled. Make a note of versions that are installed but not assigned to any domain. They should also be updated or removed.
Putting backports in context
As with other vendors: the displayed version number is not the only yardstick. If a fix is delivered as a backport, the number can stay unchanged. So also check the package's changelog and the vendor's notes.
# Search a package's changelog for CVE numbers (example)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'
If no entry turns up, that does not automatically mean the fix is missing. It does mean you need written confirmation before you classify the server as patched. How to read versions correctly is described in Checking the PHP version and patch level.
Update, restart and verification
You apply the update in WHM through the system update or through the package manager. After that, you restart all PHP processes. New files alone are not enough as long as old processes keep running in memory.
# Restart the PHP-FPM services of all versions (cPanel script)
/scripts/restartsrv_apache_php_fpm
# Restart Apache completely
/scripts/restartsrv_httpd
# Check the start time of the PHP processes
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep
Every PHP process should have a start time after the update. If that is not the case, end it deliberately through the service it belongs to. With several servers, a short log per machine is worthwhile, which you can use as evidence later.
A CMS update through cPanel tools such as WP Toolkit does not close the PHP vulnerability. It is worthwhile, but it replaces neither the PHP update nor the restart.
Setting interim values centrally
If a version has not been fixed yet, php.net recommends interim measures that do not offer complete protection. On cPanel, you set these in the MultiPHP INI Editor in administrator mode or directly in the php.ini of the respective ea-php version. Values in the customer accounts' .user.ini are not sufficient for session.upload_progress.enabled.
; server-wide php.ini of the affected version (example)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M
Without an upload function, php.net gives post_max_size = 8M. On PHP 8.5, fatal_error_backtraces=0 is added. After that, you restart all workers again. You set a memory limit through cgroups, for example with the CloudLinux limits, not through RLIMIT_AS or RLIMIT_DATA. More details are under Immediate measures without a patch.
Responsibility between server operator and account holders
On a cPanel server with many accounts, the WHM administrator is responsible for PHP, services and server-wide configuration. The holders of individual accounts are responsible for their applications, plugins and credentials. Tell the account holders when and how patching was done, and recommend that they check their applications for anything unusual. How the situation looks from the customer's side is described under Shared hosting.
Keep the logs from 20 October 2026 onward. A patch does not remove malware that was planted earlier.
For the evidence, a plain log per server is enough: date and time of the update, a list of the ea-php and alt-php packages with the version before and after, the process list with start times after the restart and, where applicable, the package supplier's confirmation on backports. Store the log outside the server. Later it serves as proof towards customers, insurers or auditors and makes the next emergency update easier, because the steps are already written down. If you run several cPanel servers, it is worth putting the read commands from this page into a small script that runs identically on all machines and collects the results. That way you spot differences between servers, such as a forgotten PHP version, at a glance.
How does PHP SOS help?
- We take an inventory of ea-php, alt-php and system packages and assign every account to its PHP version.
- Through our PHP patch service, we update, restart all services and document the state with package lists and process times.
- Where necessary, we set interim values server-wide and in a way that cannot be overridden.
- We check the accounts for typical traces of a compromise and, if we find any, start malware removal.
- Afterwards, we reduce the number of PHP versions and harden the configuration.
Frequently asked questions
Where do I see in WHM which domain uses which PHP version?
In the MultiPHP Manager in WHM you see the assigned version for each domain and whether PHP-FPM is active. For a complete list, a command-line query is also useful. Also note versions that are not assigned to any domain.
May a cPanel customer set the interim values in .user.ini themselves?
For session.upload_progress.enabled, php.net explicitly states that .user.ini and ini_set() are not sufficient. The value belongs in php.ini, the FPM pool or the server configuration. Only the server administrator can do that.
Is a graceful restart of Apache enough?
With PHP-FPM, the FPM services themselves must restart; an Apache reload does not renew them. With Apache-based PHP handlers, a full restart is the safe route. Afterwards, check the start time of all PHP processes.
What about CloudLinux and alt-php?
On CloudLinux servers, websites sometimes run with their own alt-php packages instead of ea-php. These have their own package state and must be checked and updated separately.