PHP Warns of a New RCE Path in Session Upload Progress (CVE-2026-115560)

PHP has warned of a remote code execution path in session upload progress that has no patch yet. It is tracked as CVE-2026-115560. PHP posted an informational advisory on 23 October 2026, two days after the PHP2Shell fixes, and calls the issue unlikely in practice. Its stopgap is one setting: session.upload_progress.enabled=0.

Free PHP2Shell Vulnerability CheckSee which PHP version your site shows to the outside world and whether it falls in the CVE-2026-109618 and CVE-2026-109619 range. Passive check, no account, no exploit traffic.Check Your Site →

Our free check above compares the PHP version a site shows with the range of CVE-2026-109618 and CVE-2026-109619. It does not test for CVE-2026-115560. This flaw depends on application code, and PHP has named no fixed version to compare.

What Has PHP Said So Far?

The note on php.net, titled “Informational advisory: Session upload progress”, suggests turning upload progress off until the next regular bugfix release. PHP says this fully protects against an “unlikely RCE vector”. It adds that the same setting was already a mitigation in its advisory for CVE-2026-109619 on 21 October, so anyone who applied it then has nothing more to do.

PHP is handling the issue in its regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release. It has given no date. Its note does not say that the 21 October releases (8.5.12, 8.4.27, 8.3.36 and 8.2.35) fix this issue.

When we looked at 18:42 UTC on 23 October, the NVD and the CVE program had no record for the id, so no official CVSS score exists yet. The CISA Known Exploited Vulnerabilities file released that day does not list it.

Who Is Affected?

PHP says the issue needs an unusual mix of configuration and application code. 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 it calls session_start().
• Session upload progress is still enabled. The PHP manual lists it as on by default.

Applications that never change the serialize handler at runtime can keep the feature on, says PHP. Because the trigger sits in your own code, nobody can tell from outside which sites match. Search your code before you decide.

How Do You Turn Off Upload Progress Safely?

1. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then restart every PHP worker. PHP’s CVE-2026-109619 advisory says to set it administratively and restart every worker. PHP’s 21 October security note adds that the setting must apply before request parsing, so do not rely on ini_set() or FPM .user.ini.
2. Search your code and configuration for session.serialize_handler and for ini_set calls that change it. A match that runs before session_start() is the case PHP describes.
3. Check whether any page reads upload progress from the session to draw a progress bar. Turning the feature off would stop such a bar from working, so test the upload form.
4. Apply the PHP2Shell updates if you have not yet. PHP released them on 21 October, and our PHP2Shell analysis lists the versions.
5. Watch php.net for the next bugfix release and the full advisory, and then update.

The setting is worth keeping off even after patching if you do not use the feature. PHP’s CVE-2026-109619 advisory says this may be prudent, because attackers look for flaws in a “hardly-used and hardly-tested feature”.

How Does It Relate to PHP2Shell?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical flaws fixed on 21 October. CVE-2026-115560 is a separate id. PHP’s advisory for CVE-2026-109619 already describes a session upload progress case, and that is why the same setting appears in both.

Sources differ on which id covers which path. VulnCheck links the upload-progress scans it saw to CVE-2026-109618. PHP gives CVE-2026-115560 to the serializer switch described above. Until PHP’s full advisory is out, match your systems by the setting, not by the id alone. Our PHP2Shell timeline follows how the first days unfolded, and the PHP end-of-life dates show which branches get no fix at all.

What Are GitHub, X and Dark Web Posts Saying About CVE-2026-115560?

GitHub: on 23 October our search found six public repositories that name the id. Three were created that day, between 16:37 and 18:31 UTC. The newest says it holds a local lab on PHP 8.5.12 that turns the serializer switch into object injection and then code execution. That is the author’s claim and we have not verified it.

Its own text says no CVSS score, weakness type or affected range has been published. The other three began on 21 October as PHP2Shell toolkits or hardening notes and now name the new id. We did not run or link any of them.

X: our search for the id and for upload-progress talk found 41 unique public posts on 23 October. Most repeat the news and the mitigation. Two come from organisations: Chile’s national cybersecurity agency and a hosting provider.

“a new related vulnerability, CVE-2026-115560” (our translation), @ANCIChile, 23 October. Chile’s national cybersecurity agency added the id to its PHP alert, with background on PHP2Shell exploitation attempts observed since 17 October.

“the same mitigation we applied on all xCloud servers”, @xCloud_host, 23 October. The hosting service says it set the same mitigation on 21 October and will install the official fix.

Dark web: our THANOS search returned nine results for the id, all dated 23 October, from eight Telegram channels and one forum. Seven repeat press coverage, including a Russian-language forum thread and translated copies. A Russian-language Telegram channel told readers the 21 October PHP patches were not good enough and pointed them to PHP’s upload-progress advice. We have not verified any of these claims.

What Has PHP Not Published Yet?

PHP’s note gives no affected versions, no severity score and no fixed release. Those will come with its full advisory. Until then, the setting above is the control PHP names, and the conditions it lists are the way to judge your own exposure. We will update this post and the CVE-2026-115560 vulnerability page when PHP publishes more.