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.

Advisory card: PHP CVE-2026-115560, session upload progress, no patch yet, mitigation session.upload_progress.enabled=0
Illustration: THE JDNEER. Source: php.net.

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_handler to php_binary or php_serialize in its configuration.
  • It then switches the handler to php at runtime with ini_set() before calling session_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 -v

Does your code switch the serialize handler at runtime?

grep -rn 'serialize_handler' /var/www --include=*.php

No 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 => Off

Your 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.