Skip to content

PHP Session Upload Progress Advisory (CVE-2026-115560): Keep It Disabled for Now

The PHP security team recommends keeping session.upload_progress.enabled=0 until the next regular release to close an unlikely RCE path (CVE-2026-115560). Here is who is actually affected and how to check in two minutes.

PHP session upload progress advisory: keep session.upload_progress.enabled off

Two days after the emergency PHP2Shell patches, the PHP security team published a short informational advisory about PHP session upload progress. The message is simple: set session.upload_progress.enabled=0 and keep it that way until the next regular bugfix release, to fully protect against an unlikely remote code execution (RCE) path.

The good news: if you already disabled it on October 21 as a mitigation for CVE-2026-109619, you’re done. Keep the setting in place.

What the advisory says

  • A new issue, tracked as CVE-2026-115560, can lead to RCE through the session upload progress feature.
  • Disabling session upload progress was already listed as a mitigation in advisory GHSA-6wmf-4rv5-p3rp for CVE-2026-109619, published on 21 October 2026.
  • Because the vulnerable setup is rare, PHP is fixing it in the regular release cycle, not with another emergency release. A full advisory for CVE-2026-115560 will be published with that release.

Who is actually affected

The issue only appears when all three of these are true:

  1. The configuration sets session.serialize_handler to php_binary or php_serialize.
  2. The application then switches it back to php at runtime with ini_set() before calling session_start().
  3. Session upload progress is still enabled (it is on by default).

If your application never changes the serialize handler at runtime, you can keep the feature enabled. Most Laravel, Symfony and WordPress setups don’t use PHP’s native session serializer switching at all, so the real-world exposure is small.

How to check your server in two minutes

1. See the current settings (run it on the CLI, and ideally also from a web-served phpinfo() page, since FPM and CLI often use different php.ini files):

php -i | grep -E 'session.serialize_handler|session.upload_progress.enabled'

2. Search your code, including vendor packages, for runtime changes to the handler:

grep -rn "serialize_handler" /var/www --include='*.php'

If both the config and the code match the pattern above, you’re in the risky group.

The fix: disable session upload progress

Set it in php.ini or your PHP-FPM pool, then restart PHP-FPM or Apache:

# php.ini
session.upload_progress.enabled = 0

# or in the FPM pool (e.g. /etc/php/8.4/fpm/pool.d/www.conf)
php_admin_flag[session.upload_progress.enabled] = off
sudo systemctl restart php8.4-fpm   # or: sudo systemctl restart apache2

On shared hosting, ask your provider or use the PHP options in your control panel. The only visible change: progress bars built on PHP’s native upload progress stop updating. File uploads themselves keep working.

Bottom line

  • Already patched for PHP2Shell and disabled upload progress? No action needed.
  • Patched but left upload progress on? Turning it off is a quick, low-risk win.
  • Still not on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35? That’s the bigger priority. Update first.
  • Watch for the next regular PHP release, which will include the full CVE-2026-115560 fix.

Managing several PHP servers or apps and want a second pair of eyes? Get in touch and we’ll audit and harden them.

Sources: PHP Security Team informational advisory, TryHackMe: php2shell patch.

Share
Working on something similar?

I take on a small number of projects at a time. Tell me what you are building and I will tell you honestly whether I am the right person for it.

Get in touch →

Leave a Reply

Your email address will not be published. Required fields are marked *