PHP CVE-2026-115560 only hits apps that switch serialize_handler to php at runtime

TL;DR

---

php2shell is the nickname for the two unauthenticated RCE flaws PHP fixed on October 21 (CVE-2026-109618 and CVE-2026-109619).
Two days after those releases, PHP posted a notice carrying a new CVE number (PHP news).
The notice is titled “Informational advisory: Session upload progress” and went up at 10:12 UTC on October 23.
CVE-2026-115560 is a separate issue from the two php2shell flaws, and it is still present on servers that installed the October 21 releases (The Hacker News).

PHP says it will fix this in the regular release cycle rather than with an emergency release.
When the conditions line up, an attacker could run code on the server remotely (remote code execution, RCE), but PHP writes that the combination is unusual and unlikely in practice.
Until the fix ships, it recommends session.upload_progress.enabled=0, the same setting covered before the php2shell releases.

The three conditions

According to PHP’s notice, the issue occurs only when the configuration and the application code meet all three of these.

Condition	Details
Configuration	php.ini or another config file sets session.serialize_handler to php_binary or php_serialize
Application code	At runtime, the app switches session.serialize_handler to php with ini_set() (a function that changes a setting while the script runs) and then calls session_start()
Upload progress	session.upload_progress.enabled is still on

session.serialize_handler decides the format used when the contents of $_SESSION are written to a file or other storage.
The PHP manual lists php as the default; php_binary is another internal PHP format, and php_serialize uses serialize() and unserialize() directly.
If the setting is left at the default and the app never switches it, the first two conditions do not apply.

session.upload_progress.enabled makes PHP write the progress of a file upload into the session while the upload runs, and it is on by default.
PHP says apps that never change session.serialize_handler at runtime can keep the feature enabled.
The notice does not explain how upload progress tracking interacts with the format switch to cause the problem.

Servers that turned the setting off on October 21 need nothing more

session.upload_progress.enabled=0 was already listed as a mitigation in the October 21 advisory for CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp).
PHP writes that if you applied it then, you should keep it in place and no further action is needed.

If you have not set it yet, set it and keep it until the next regular release.
For CVE-2026-109619, the October 21 advisory asked admins to put this setting in php.ini, an FPM pool (the unit of configuration for a group of PHP-FPM workers), or the server configuration, and to restart every worker (the long-running processes that handle requests).
It also said not to rely on ini_set() or FPM’s .user.ini.
The October 23 notice says nothing about where to set it.
Putting it in the same places as on October 21 also meets the conditions of the CVE-2026-109619 mitigation.
Steps for shared hosting and php.ini are in the earlier article written before the fixed releases.

This setting stops PHP from recording upload progress in the session.
Sites that drive an upload progress bar from this feature will stop showing progress.
Lolipop, a Japanese shared host, turned session.upload_progress off for every PHP version on October 22 (Lolipop notice, in Japanese), so its customers are already in this state without changing anything themselves.

Checking whether your app meets the conditions

Check both the configuration and the code.
Searching config files and application code for session.serialize_handler shows where it is set.

# Config files (adjust the paths to your system)
grep -rn "serialize_handler" /etc/php* /etc/httpd /etc/apache2 2>/dev/null

# Application code, .htaccess, .user.ini
grep -rn "serialize_handler" /var/www --include="*.php" --include=".htaccess" --include=".user.ini"

If the configuration sets php_binary or php_serialize and the code contains ini_set('session.serialize_handler', 'php'), the first two conditions apply.
The runtime switch can sit in a library installed with Composer (PHP’s package manager, under vendor/), not only in the app itself.
The notice does not say whether switching through php_value in .htaccess (Apache’s per-directory config file) or through .user.ini (PHP’s per-directory config file) counts.
The only runtime switch PHP names is ini_set().

What PHP has not published yet

The October 23 notice is informational. PHP says it will publish the full advisory for CVE-2026-115560 with the next release, alongside the fix.
According to The Hacker News, the following were not available as of October 23.

Item	As of October 23
Affected versions	Not published
Release with the fix	Only “the next regular bugfix release”
Severity score (CVSS, a 0 to 10 scale)	Not published
Same root cause as CVE-2026-109619?	Not stated
Exploitation	None reported. Attacks seen since October 21 target the two flaws fixed on October 21

How this relates to the “still survives after the patch” claims

The previous article covered a self-published page (php2shell-zeros) claiming unauthenticated (no login required) RCE still survives on the patched 8.5.12.
Item A of its “Zero 1” claimed that when the session write path and read path use different session.serialize_handler values, an attacker can make PHP construct an object of the attacker’s choosing.
If that object’s class has __wakeup() or __destruct(), those methods run automatically when the object is restored or torn down, which the page says leads to running the attacker’s code.
As causes of the mismatch, it listed per-directory php_value, vhost configuration, .htaccess, and an app-level ini_set().

PHP’s three conditions also describe a mismatch between the configuration and an app’s ini_set() for session.serialize_handler, which resembles that claim.
PHP’s notice does not name a reporter or say how the issue was found, so it is unclear whether both refer to the same problem.
When the previous article was written, Zero 1 had not been formally reported to PHP.
The scope of the mismatch also differs: the page includes switching through .htaccess and similar, while PHP names only the combination of php.ini-style configuration and ini_set().