PHP CVE-2026-115560: Disable Session Upload Progress Until the Next Release
PHP.net recommends setting session.upload_progress.enabled=0 to block an unlikely RCE vector, CVE-2026-115560. No patch yet; the fix comes in the next regular release. Only apps that switch serialize_handler to php at runtime are exposed.
On October 23, the PHP project posted an informational advisory about session upload progress. It describes a remote code execution vector, now tracked as CVE-2026-115560, and asks admins to flip one setting until the next regular bugfix release. There is no patch yet. PHP says it will publish a full advisory for the CVE with that release.
Before anyone panics: PHP itself calls this an "unlikely RCE vector" that "can only occur under an unusual combination of configuration and application code." Here is what that combination is, how to check for it, and the one-line fix.
What PHP said
The recommendation, in PHP's words: "We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector."
The same setting was already listed as a mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619, published October 21. If you applied it then, PHP says to keep it in place and no further action is needed. (CVE-2026-109619 itself is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, so if you have not updated for that one, do it first.)
Who is exposed
According to the advisory, all three of these must be true:
- The application sets
session.serialize_handlertophp_binaryorphp_serializein its configuration. - It then switches the handler to
phpat runtime withini_set()before callingsession_start(). - Session upload progress is still enabled.
Applications that never change the serialize handler at runtime can keep the feature enabled. The advisory does not mention any exploitation, and I am not aware of a verified public proof of concept.
Are you affected?
- Is your configured handler php_binary or php_serialize? If it is already
php(the default) and never changes, this vector does not apply.
Are you patched for CVE-2026-109619?
php -vDoes your code switch the serialize handler at runtime?
grep -rn 'serialize_handler' /var/www --include=*.phpNo ini_set('session.serialize_handler', 'php') before session_start() means you are not exposed.
Is session upload progress on? It is enabled by default.
php -i | grep -E 'session.upload_progress.enabled|session.serialize_handler'Check the web SAPI too (a phpinfo() page or your FPM pool config), since CLI settings can differ.
The fix for now
Set the option in php.ini (or php_admin_value in your FPM pool) and reload PHP:
[root@web ~]# cat /etc/php.ini | grep upload_progress.enabled
session.upload_progress.enabled = 0
[root@web ~]# systemctl reload php-fpm
[root@web ~]# php -i | grep upload_progress.enabled
session.upload_progress.enabled => Off => OffYour php.ini path and service name may differ; php --ini shows which file is loaded. The only thing you lose is upload progress tracking in sessions, which most sites never use.
My take
This is a narrow issue with an easy, low-cost mitigation, and PHP handled it sensibly by flagging it early instead of rushing a release. If you applied the setting for CVE-2026-109619 this week, you are done. If not, take two minutes and turn it off, then watch for the next regular PHP release.
Source: PHP News Archive 2026, "Informational advisory: Session upload progress" (Oct 23, 2026); GHSA-6wmf-4rv5-p3rp.