Two days after the emergency PHP2Shell fixes, PHP published a short notice about another way to run code on a PHP server: CVE-2026-115560. It is separate from PHP2Shell, and the PHP2Shell releases do not fix it. The good news: it needs a setup PHP itself calls unlikely, and the advice is one setting most teams applied last week anyway.
Who is exposed
According to PHP's notice of 23 October, all three of these must be true:
- The configuration sets a non-default session format.
session.serialize_handlerisphp_binaryorphp_serialize. The default isphp, so a server that never touched it is not exposed. - The application switches it back while running. The code calls
ini_set('session.serialize_handler', 'php')beforesession_start(). - Session upload progress is on.
session.upload_progress.enabledis on by default.
An application that never changes the serialize handler while running is not exposed through this path, even with upload progress on.
What to do today
Set this, then restart PHP-FPM or your web server:
session.upload_progress.enabled = 0It is the same setting PHP already listed as an interim fix for one of the PHP2Shell flaws. If you applied it then, keep it and you are covered. Upload progress only powers file-upload progress bars, so few applications miss it.
PHP is fixing the bug in its next regular release instead of an emergency one, and will publish the full advisory then. It has not yet said which versions are affected or how severe the bug is, so we don't guess either.
How to check
On one PHP, one command answers it:
php -r 'echo ini_get("session.upload_progress.enabled"), " ", ini_get("session.serialize_handler"), PHP_EOL;'0 first means you're covered; php second means you're not exposed. But the command line and PHP-FPM can use different settings, and every PHP-FPM pool can override both, so one command is not the whole answer on a real server.
php2shell-check v1.1.0, our free scanner, now checks both settings for every PHP it finds, and for each PHP-FPM pool on its own:
| Result | What it means |
|---|---|
| MITIGATED | Upload progress is off: PHP's recommended setting |
| NOT_EXPOSED | The handler is not php_binary or php_serialize |
| AT_RISK | Both settings allow it. Check your code for that ini_set() call |
| UNKNOWN | Settings couldn't be read, for example Apache mod_php. Never reported as fine |
The scanner never reads or runs your application code, so it cannot see the second condition. AT_RISK means the configuration allows it: search your code for serialize_handler to finish the check.
We tested every result against what PHP itself reports, on official PHP 8.4 images and Ubuntu 24.04, and the published downloads run in our test pipeline on Linux, macOS, Windows and FreeBSD.
Building this check turned up a bug in the scanner's earlier versions. The official Docker PHP image splits its web pool across three files, and PHP-FPM merges them. Version 1.0 read each file as a separate pool, so if you turned upload progress off in your own file, the normal Docker way, it reported the setting as not applied. It failed safe, but it was a false alarm on exactly the fix PHP recommends. Version 1.1 merges pools the way PHP-FPM does. If version 1.0 flagged a Docker image you had already fixed, scan it again.
Meanwhile, PHP2Shell is the real fire
No attacks on CVE-2026-115560 have been reported. The two PHP2Shell flaws are another matter: The Hacker News, citing Cloudflare, reports exploit attempts rising from tens of thousands in the first 45 minutes after disclosure to millions a day later. If anything still shows VULNERABLE, patch that first.
We ran these same checks on our own platform: what we found.
This post also appears on our developer blog, adzoic.github.io.
