New PHP Issue Two Days After PHP2Shell: What WordPress Agencies Should Know
PHP’s new advisory, CVE-2026-115560, isn’t another emergency. Find out why most WordPress sites aren’t exposed, which setting PHP recommends, and why confirming your PHP2Shell updates should still come first.
Two days after fixing PHP2Shell, the PHP team shared a new warning about the same part of PHP. This time, the risk is much lower and there’s no emergency fix. Here’s what’s different, what it means for WordPress sites, and what to do.
TL;DR
- On October 23, 2026, PHP published an informational advisory about a new issue, CVE-2026-115560, in a PHP feature called session upload progress.
- It can let an attacker run code on a server, but only in an unusual setup that PHP calls unlikely in practice. PHP will fix it in the next regular release, not with an emergency update.
- The October 21 PHP updates that fixed PHP2Shell don’t fix this new issue.
- PHP recommends one setting: session.upload_progress.enabled=0. If you already applied it for PHP2Shell, you don’t need to do anything else.
- The bigger priority is still PHP2Shell: make sure every site actually runs a fixed PHP version.
What PHP announced
On October 21, PHP released emergency updates for PHP2Shell, two critical vulnerabilities in PHP itself. If you missed it, our PHP2Shell guide explains what happened and what to do.
On October 23, PHP shared a new notice about CVE-2026-115560. Like one of the PHP2Shell vulnerabilities (CVE-2026-109619), it involves session upload progress. This PHP feature lets a site show a progress bar while a file is uploading.
The new issue can also lead to remote code execution, which means an attacker running their own commands on the server. The big difference is how hard it is to trigger.
Why This One Is Lower Risk
PHP2Shell could be triggered on a normal server with a single request, before any website code even ran. The new issue needs a very specific combination of settings and code. According to PHP, all of these must be true at once:
- The server’s PHP settings set session.serialize_handler (the way PHP saves session data) to php_binary or php_serialize.
- The site’s code switches that setting to php while the site is running, using ini_set().
- It does this before starting the session with session_start().
- Session upload progress is still turned on.
If a site never changes how session data is saved while it runs, it isn’t exposed through this issue. That’s why PHP is handling it in its regular release cycle instead of with an emergency update.
At the time of writing, no attacks using this issue have been reported. The attacks seen since October 21 have targeted the PHP2Shell vulnerabilities.
What It Means for WordPress
WordPress core doesn’t use PHP sessions, so it never changes how session data is saved. For a WordPress site to be at risk, a plugin, theme or piece of custom code would need to use PHP sessions and change the session setting while the site runs, exactly as described above. That’s rare.
Rare isn’t the same as impossible, though, especially on sites with older plugins or custom code you didn’t write yourself. That’s why PHP’s recommended setting is still worth applying.
What WordPress Agencies Should Do
1. Finish your PHP2Shell checks first
PHP2Shell is the bigger risk, and attacks have been reported. Make sure every site runs one of the fixed versions: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a version your host has patched.
2. Turn off session upload progress
PHP’s advice is to set session.upload_progress.enabled=0 until the next regular release. WordPress core doesn’t use this feature, so turning it off rarely causes problems. If you already did this for PHP2Shell, keep it in place.
How you apply it matters. According to PHP’s October 21 advisory, the setting should go in php.ini, the PHP-FPM pool or the server configuration, followed by a restart of every PHP worker. It shouldn’t be set from the site’s code with ini_set() or in a .user.ini file on PHP-FPM, because those are applied too late.
On most hosting plans, you’ll need to ask your host to do this.
3. Check your custom code
If your team writes custom plugins or themes, search them for code that changes session.serialize_handler, for example ini_set(‘session.serialize_handler’, …). If you find it, that site matches part of the risky setup, so make sure session upload progress is off there.
4. Plan your PHP 8.2 upgrades
PHP 8.2 received the PHP2Shell fix, but PHP has confirmed it reaches end of life on December 31, 2026. After that date, it won’t get security fixes, including fixes for issues like this one. If some client sites still run PHP 8.2, now is a good time to plan their move to PHP 8.3 or later. WordPress.org lists the PHP versions it recommends.
5. Keep watching for signs of an attack
Attacks on PHP2Shell may continue for a while, especially against servers that haven’t been updated yet. Keep an eye out for new admin users you didn’t create and PHP files you don’t recognize.
Final Thoughts
After a week like this one, it’s easy to treat every new PHP notice as another emergency. This one isn’t. PHP explained clearly who is at risk, gave a simple setting to block it, and chose to fix it on the normal schedule.
For most WordPress agencies, this advisory mostly serves as a reminder to finish what PHP2Shell started: confirm every site is on a fixed PHP version, make sure session upload progress is off, and plan the move away from PHP 8.2 before the end of the year.