TLDR:
- PHP disclosed a second RCE path on October 23, two days after the emergency PHP2Shell fixes.
- CVE-2026-115560 is tied to session upload progress and runtime changes to the serialize handler.
- Mitigation is one INI line: session.upload_progress.enabled=0.
- If you already applied that after the October 21 PHP2Shell advisory, you are already covered for this one.
- Preconditions are narrow but worth checking.
Two days after PHP shipped emergency patches for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), the project is back with another RCE advisory: CVE-2026-115560.
Looks like PHPoclypse is going to stick around till the weekend. In this blog, we break down what CVE-2026-115560 actually is, the narrow configuration that makes it exploitable, and the one-line mitigation you can apply before the weekend.
PHP itself is calling this one “unlikely,” telling the world that another path to code execution exists and that the fix will arrive on the regular release train.
What CVE-2026-115560 Actually Is
PHP’s advisory frames CVE-2026-115560 as a code execution issue reachable only through a specific sequence of session-handling moves. The vulnerable surface is session.upload_progress, the built-in feature that writes upload progress data into $_SESSION so applications can show progress bars without a separate backend. It is enabled by default.
The bug fires when all of the following line up in the same request path:
- session.serialize_handler is set to
php_binary or php_serializeinphp.inior an equivalent config layer - The application then calls
ini_set('session.serialize_handler', 'php') at runtime, flipping the handler to the legacy format - That
ini_set()call happens beforesession_start() session.upload_progress.enabledis still 1
PHP has not published the technical root cause yet but told there is a chance for RCE.
Is your PHP vulnerable to PHP2Shell? Run a free check to find out.
Mitigation for CVE-2026-115560
For this CVE-2026-115560, PHP shared the same fix as the October 21 advisory for CVE-2026-109619:
ini
session.upload_progress.enabled = 0Set it administratively, the way PHP’s advisory asks. In FPM, that’s php_admin_flag[session.upload_progress.enabled] = off in your pool config.
In Apache with mod_php, it’s php_admin_flag session.upload_progress.enabled off. The administrative flag matters here because application code cannot override php_admin_* with ini_set(), and ini_set() is exactly how this bug is reached.
Restart every worker after the change. Do not just reload. Then verify on the SAPI that actually serves your site, not the CLI. php -i reads the CLI config and will mislead you.
Use php-fpm -i | grep session.upload_progress, or open a phpinfo() page through the web server to confirm the setting is live where it counts.
Nothing in a typical web application depends on this feature. It only matters if you are actively rendering an upload progress UI from $_SESSION. If you are, swap to a client-side progress indicator until the routine fix ships. The browser already emits progress events on XMLHttpRequest and fetch uploads, so the replacement is straightforward.
If you applied this mitigation for PHP2Shell and never rolled it back, you are done. CVE-2026-115560 does not need a second action..
Patch Status
| CVE | Status | Patched Versions |
| CVE-2026-109618 (PHP2Shell) | Patched Oct 21 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| CVE-2026-109619 (PHP2Shell) | Patched Oct 21 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| CVE-2026-115560 | Unpatched; fix queued for next routine release | TBD |
PHP has not confirmed which branches are affected by CVE-2026-115560 or whether the fix will backport across all supported lines. Assume it will, plan accordingly, and keep the INI mitigation in place until the next routine release lands and you have verified the fix on your version.
Automate the check with our open-source triage skill: Because php -v can report a different binary from the one serving traffic, we built php2shell-triage, a free Claude skill and plugin for defenders. Its read-only assessor walks /proc to find the real binary behind every running PHP-FPM, Apache, and CLI worker.
It also flags workers still running an old binary after an upgrade, and tells distro-backported fixes apart from vulnerable builds. It then guides you through hunting for signs of exploitation and the remediation steps. It runs only on hosts you own and contains no exploit code
What To Do Before The Weekend
- Not patched PHP2Shell yet? That is still the higher priority task. Those CVEs are being exploited in the wild. CVE-2026-115560 is not.
- Set session.upload_progress.enabled = 0 everywhere. Leave it set until the next routine PHP release lands, and you verify the fix.
- Grep your codebase and config layers for runtime ini_set calls against session.serialize_handler. If you find any, you are the narrow case.
- Watch php.net and the php-src security advisories page for the full CVE-2026-115560 write-up.
PHP calling an RCE “unlikely” is not the same as it being safe to ignore. It is a release decision, not a risk assessment for your specific stack. The one-line mitigation costs nothing. Apply it and move on.
How Astra Helps
Astra’s DAST and AP detect both PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) for our existing customers. Run a scan on an unpatched PHP app and both CVEs are flagged with context on the exposure and what to patch to.
We have also released a free PHP2Shell scanner that anyone can run without an Astra account. Point it at your endpoints, get a quick read on whether CVE-2026-109618 and CVE-2026-109619 are exposed, and move on with the patch plan. [Link to the scanner]
Once more information arrives on CVE-2026-115560, we will update here with coverage details.
Disclaimer: This is an evolving situation. As of October 23, 2026, PHP has not published affected version ranges, a CVSS score, a target release for the fix, or confirmation of whether CVE-2026-115560 shares a root cause with CVE-2026-109619.
