In short: CVE-2026-115560 is an advisory that php.net published on 23 October 2026. According to it, remote code execution is only possible with an unusual session configuration. Until the next regular bugfix release, the remedy is: set session.upload_progress.enabled=0 on the server side and restart all workers.
What is CVE-2026-115560?
Two days after the patches for the PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619, the PHP project published a further advisory. CVE-2026-115560 concerns PHP's session handling in connection with the session upload progress function, which stores the progress of running file uploads in the session.
According to php.net, remote execution of malicious code is possible, but only with an unusual configuration. The full advisory with all details is to follow with the next regular bugfix release. Until then, the state of knowledge is deliberately sparse.
What does session upload progress do?
Session upload progress is a convenience feature of PHP. When a visitor uploads a larger file, PHP continuously writes information about the progress into the session during the upload: how much data has already arrived and which file is currently being transferred. An application can query this information in parallel and build a progress bar from it.
In practice only a few applications use this, because modern upload forms usually measure progress directly in the browser. In PHP, however, the function is enabled by default. That is why it appears both with CVE-2026-115560 and in the interim measures against PHP2Shell: what is not needed should be switched off.
When is a server affected by CVE-2026-115560?
According to the php.net advisory, three conditions must come together:
- In the configuration,
session.serialize_handleris set tophp_binaryorphp_serialize. - The application switches this value to
phpat runtime viaini_set()before it callssession_start(). - Session upload progress is active.
The default value of session.serialize_handler is php. Switching it in the configuration and switching it back in code is unusual, but it does occur in grown custom developments or in libraries with their own session handling. Whether this applies to you can be checked.
How to check your configuration
First the effective values. The CLI may read a different php.ini than PHP-FPM or mod_php; so also check the configuration of the web server or FPM pool.
php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"
grep -rn "serialize_handler\|upload_progress" /etc/php/ 2>/dev/null # path differs by distribution
Then the application code. The following search is read-only and shows places where the handler is set at runtime:
grep -rn "session.serialize_handler" /var/www/ --include="*.php"
If the search finds nothing and the handler in the configuration is php, the described combination is unlikely. You should still disable session upload progress, because php.net also lists the same setting as an interim measure against PHP2Shell.
Remedy: session.upload_progress.enabled=0
Set the value in php.ini, in the FPM pool or in the server configuration. According to php.net, explicitly not via ini_set() or .user.ini, because there it takes effect too late or can be overridden by the application.
; php.ini (for all pools and SAPIs that read this file)
session.upload_progress.enabled = 0
; or in the FPM pool
php_admin_flag[session.upload_progress.enabled] = off
# Apache with mod_php, in the VirtualHost or in the server configuration
php_admin_flag session.upload_progress.enabled off
Then restart all PHP workers, for example systemctl restart php8.3-fpm or, with mod_php, Apache. Package and service names differ by distribution. Without a restart, the old setting stays in force. More at Restarting PHP-FPM and all workers.
After the restart, check that the setting really takes effect: in the web context, not only on the command line. A briefly set up, access-protected phpinfo page shows the effective value; delete it again immediately afterwards.
Putting it next to PHP2Shell
CVE-2026-115560 is much narrower than the two PHP2Shell vulnerabilities, which take effect in the usual operating modes without any special configuration. Anyone who has to prioritise should first install the PHP2Shell update and then set session.upload_progress.enabled=0. Both together are feasible in one maintenance window.
For management and non-technical readers: CVE-2026-115560 is no reason for alarm, but it is an item on the list. The setting is quickly applied, has a noticeable effect on hardly any application and at the same time covers one of the interim measures against PHP2Shell. The further interim measures from php.net are at Immediate measures if you cannot patch yet, and general notes on session configuration at Securing sessions in PHP.
What we do not yet know: exactly which PHP versions are affected and which release brings the fix. We will update this page as soon as the advisory is published.
How does PHP SOS help?
As part of server hardening, we implement the remedy permanently and verifiably:
- Read the configuration: effective session values per SAPI, pool and virtual host.
- Search the code: places where handlers or session options are changed at runtime.
- Disable at the right place: in php.ini, pool or server configuration, not overridable by the application, followed by a restart.
- Follow up: when the bugfix release is published, we install it and document the state.
Frequently asked questions
Is CVE-2026-115560 part of PHP2Shell?
The advisory came two days after the PHP2Shell patches and also concerns PHP itself. It is, however, a separate vulnerability with its own CVE number and only takes effect with a specific, unusual configuration. According to current information, the PHP2Shell updates of 21 October do not fix it.
Is there already an update against CVE-2026-115560?
As of 25 October 2026, no. php.net announces that the full advisory will follow with the next regular bugfix release. Until then, session.upload_progress.enabled=0 is the recommended remedy.
What breaks if I disable session upload progress?
The function reports the progress of running file uploads to the application. Only applications that implement such a progress bar via this PHP function lose the display. The upload itself keeps working.