CVE-2026-115560: PHP Warns of Another Unpatched RCE Path Days After PHP2Shell

Two days after shipping emergency fixes for the PHP2Shell flaws, PHP warned about another possible way to run code on a web server. On October 23, 2026, the project published an informational advisory on CVE-2026-115560, a remote code execution vector tied to session upload progress. PHP calls it unlikely, will not issue an emergency release for it, and plans to fix it in the next regular release.

The interim advice is one line: set session.upload_progress.enabled=0 until that release arrives. Teams that already applied that setting for CVE-2026-109619 on October 21 need to do nothing more. This post covers what PHP has said, what it has not, and how to keep this new issue separate from the PHP2Shell attacks that are already under way.

What PHP has said so far

PHP's notice gives conditions, not mechanics. It says the problem can only occur under an unusual combination of configuration and application code. Three things have to be true together:

1. The application sets session.serialize_handler to php_binary or php_serialize in its configuration.
2. The application then switches the handler to php at runtime with ini_set(), before it calls session_start().
3. Session upload progress is still turned on.

PHP adds that applications which never change the serialize handler at runtime can keep the feature enabled. The PHP Foundation's post on X puts it the same way: only apps with a non-default serialize_handler that they switch to php at runtime can be affected.

What PHP has not published is longer. The notice does not say whether the flaw can be triggered without logging in, what request reaches it, which PHP versions contain it, or how severe it is, and it gives no CVSS score. It does not say whether the fix is already in the October 21 releases, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, though handling it in the regular release cycle implies that it is not. It also does not say whether the bug shares a root cause with CVE-2026-109619, which also involves the session upload progress path. NVD had no record for CVE-2026-115560 when read, and the CVE number so far appears only in PHP's own announcement and the coverage that quotes it.

Who is affected

PHP has not named affected versions, so the useful question is which applications match the pattern, not which version number you run. An application is only in scope if its own code or configuration leaves the session serialize handler at php_binary or php_serialize and switches it back to php during a request. That is a rare setup, and PHP considers it unlikely in practice. Many PHP sites never touch the serialize handler at all, and those fall outside the described conditions.

Two things are still worth checking. First, search your codebase and configuration for session.serialize_handler and for ini_set calls that change it, including in plugins, frameworks and old custom code. Second, remember that session upload progress is on by default, so the feature is active unless someone turned it off.

This advisory does not replace the October 21 patches. CVE-2026-109618 and CVE-2026-109619 are separate, far broader flaws, rated 9.2 by PHP, and they remain the urgent items. Servers still on versions older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 should be updated regardless of what they do with the serialize handler.

Keep the new issue apart from the attacks already under way

A second PHP warning in three days invites the assumption that the activity in your logs is about it. The reporting says otherwise. THN's account of the October 23 advisory states that no exploitation of CVE-2026-115560 has been reported, and that the attacks seen since October 21 target the two earlier PHP2Shell flaws.

Those attacks are real, though their success is not. Amazon says its honeypots logged an exploit attempt against CVE-2026-109618 and CVE-2026-109619 on October 17, four days before PHP disclosed them. Cloudflare reports attempts rose from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22. Attackers have tried to use the flaws to install a Mirai botnet variant, according to Sophos and Arctic Wolf, and those attempts have so far failed. Previdian, Wordfence and other researchers report scanning and probing with no confirmed code execution, and say a reliable exploit is proving harder to build than expected.

That gap between attempts and successes is the useful context for this new advisory. Scanning traffic tells you attackers are looking at PHP, not that a given server is vulnerable to CVE-2026-115560. It also shows the value of the cheap measure: a team that set session.upload_progress.enabled=0 on October 21 is already covered for this vector, and PHP says no further action is needed.

The setting is still a mitigation, not a cure. PHP's October 21 advisory said it blocks the confirmed session paths but not other variants of the PHP2Shell bugs, and at least one research group argues that .ini-based mitigations are ineffective. The update to the October 21 releases stays the real fix for CVE-2026-109618 and CVE-2026-109619, and the next regular PHP release is the fix to wait for here.

What to do now

The work is small, and most of it is confirming what you already did on October 21.

1. Set session.upload_progress.enabled=0. PHP's October 21 advice for CVE-2026-109619 says to set it in php.ini or the server or FPM pool configuration, not through ini_set() or .user.ini, and to restart every worker so the change takes effect. The October 23 notice says to keep it in place if you already applied it.
2. Check whether you rely on the feature. Session upload progress powers progress bars for file uploads. If an application uses it, test the application after the change, because the progress display will stop working.
3. Look for the unusual pattern. Search code and configuration for session.serialize_handler and for ini_set calls that switch it to php at runtime. If you find none, you fall outside the conditions PHP describes, and the setting is still a sensible precaution until the fix.
4. Confirm the October 21 patches. Make sure every internet-facing PHP server runs 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor build that includes the fix. Those flaws carry the attack traffic you are seeing.
5. Plan the next update. PHP has not given a date for the regular release that will fix CVE-2026-115560, and says it will publish a full advisory then. Watch the php.net announcements, and re-evaluate when it appears.

Takeaway

CVE-2026-115560 is a small advisory with a one-line fix for now, and a reminder to finish the bigger job: patch the PHP2Shell flaws and keep session upload progress switched off. PHP has promised a full advisory with its next regular release, and the version list and severity will only appear then. If you want to follow that, you can track CVE-2026-115560 on VulnTracker and see its scores and affected versions once they are published.

References

Vendor: PHP informational advisory on session upload progress, October 23, 2026 and GHSA-6wmf-4rv5-p3rp for the related CVE-2026-109619. NVD: CVE-2026-115560. Analysis: SecurityWeek on PHP2Shell exploitation, THN on PHP2Shell exploit attempts and watchTowr.