On 23 October 2026, two days after the PHP2Shell releases, the PHP project published an informational advisory for CVE-2026-115560: a remote code execution path in session upload progress handling. There is no fixed PHP release yet. PHP is fixing it in the next regular bugfix release and will publish the full advisory, with affected versions and a score, at that point.
The fix for now is one directive: session.upload_progress.enabled=0. This article shows how to set it server-wide on cPanel, CloudLinux, Plesk, and LiteSpeed, and how to stop customer sites from switching it back on. If you already set it for PHP2Shell CVE-2026-109619, PHP says to keep it in place and you need do nothing more.
Who is exposed
PHP describes it as an "unlikely RCE vector". All three conditions must hold:
session.serialize_handleris set tophp_binaryorphp_serializein configuration.- Application code switches it back to
phpwithini_set()before callingsession_start(). - Session upload progress is still enabled. It is on by default.
On a single-tenant box you can audit for condition 2. On shared hosting you can't vouch for every customer's code, so treat condition 3 as the only one you control and switch it off everywhere. No exploitation of this CVE had been reported at the time of writing. That is not true of PHP2Shell, so confirm the 21 October PHP updates are installed before you do anything else.
cPanel and EasyApache 4
Set the global value per PHP version in WHM › Software › MultiPHP INI Editor › Editor Mode. Pick each installed ea-php version and add:
session.upload_progress.enabled = Off
That writes /opt/cpanel/ea-phpXX/root/etc/php.ini. The directive is PHP_INI_PERDIR, so a customer's .htaccess or .user.ini can turn it back on. On PHP-FPM, lock it at pool level with an admin value that site files cannot override. Create or extend /var/cpanel/ApachePHPFPM/system_pool_defaults.yaml:
php_admin_value_session.upload_progress.enabled: { name: 'php_admin_value[session.upload_progress.enabled]', value: 0 }
Then rebuild the pools and restart:
/usr/local/cpanel/scripts/php_fpm_config --rebuild
/usr/local/cpanel/scripts/restartsrv_apache_php_fpm
/usr/local/cpanel/scripts/restartsrv_httpd
Per-domain overrides in /var/cpanel/userdata/<user>/<domain>.php-fpm.yaml still win over system defaults, so grep them for upload_progress. Tuning PHP-FPM pools on cPanel covers how these files layer. Domains on the DSO handler (mod_php) can't use pool values; see PHP handlers on cPanel compared for why moving them to FPM is overdue anyway.
CloudLinux alt-php
CloudLinux has one file that applies to every installed alt-php version, including ones you install later. Add the directive to /etc/cl.selector/global_php.ini:
[Global PHP Settings]
session.upload_progress.enabled = Off
Apply it:
/usr/bin/selectorctl --apply-global-php-ini
This covers sites on the CloudLinux PHP Selector. Sites that use ea-php through MultiPHP Manager still need the cPanel step above.
Plesk
Go to Tools & Settings › PHP Settings, open each PHP version, switch to the php.ini tab, and set session.upload_progress.enabled = Off. The file behind it is /opt/plesk/php/<version>/etc/php.ini. Domain-level PHP settings override the global file, so check service plans and subscriptions for custom directives. Then restart the FPM services:
systemctl restart 'plesk-php*-fpm'
Handlers that use the OS vendor's PHP rather than Plesk's builds read the distribution's php.ini. plesk bin php_handler --list shows which is which; Plesk PHP handlers compared has the details.
LiteSpeed
LiteSpeed on cPanel reads the same ea-php and alt-php ini files, so the changes above apply. A web server restart does not replace detached lsphp processes, so kill them:
pkill lsphp
Detached mode and lsphp restarts explains the trade-off.
Verify through the web SAPI
php -i shows the CLI configuration, not what FPM or lsphp serves. Check a real request: put a phpinfo() page on a test domain for each PHP version and confirm session.upload_progress.enabled shows Off in both the Local and Master columns. Delete the file afterwards. Then look for sites that re-enable it:
grep -rlis 'upload_progress' /home/*/public_html --include=.htaccess --include=.user.ini --include=php.ini
On Plesk, use /var/www/vhosts instead of /home/*/public_html.
Imunify360's PHP2Shell ruleset blocks cross-site upload progress requests, but CloudLinux has not said whether it covers this CVE. Treat Imunify360 virtual patching as an extra layer, not a fix. Fixed PHP builds will reach you through vendor update channels, which need an active cPanel license or CloudLinux license.
Is there a patch for CVE-2026-115560?+
Does the PHP2Shell update fix CVE-2026-115560?+
Can I set session.upload_progress.enabled with ini_set()?+
Will disabling session upload progress break WordPress?+
How do I check session.upload_progress.enabled on a cPanel server?+
Next steps
- Patch PHP2Shell on hosting servers if any PHP build is still on a pre-21 October package.
- MultiPHP Manager vs CloudLinux PHP Selector to cut down the number of PHP stacks you have to patch.
- Imunify360 malware cleanup workflow if a server shows signs of compromise.