CVE-2026-115560 and session.upload_progress: PHP's Follow-Up Advisory After PHP2Shell, Explained

Updated 24 October 2026.

Just as teams finished patching PHP2Shell (what it is), headlines appeared about "another unpatched PHP RCE". Here's the calm version.

What was announced

On 23 October 2026, PHP published an informational advisory for CVE-2026-115560, a separate remote code execution risk. PHP describes it as unlikely and affecting only applications "configured in an unusual way."

There is no emergency release. PHP will fix it in its regular release cycle and publish a full advisory then. As of the announcement, PHP hadn't published affected versions, a severity score, or whether it shares a root cause with CVE-2026-109619.

No exploitation of this specific issue has been reported.

Who is affected

All three conditions must be true:

1. The application sets session.serialize_handler to php_binary or php_serialize in its configuration
2. It changes it back to php at runtime with ini_set(), before calling session_start()
3. Session upload progress is still enabled

Most WordPress sites, Laravel apps and typical business websites don't do this. It's an uncommon pattern in custom or legacy code.

The mitigation: one setting

Set this in php.ini or your PHP-FPM pool configuration, then restart PHP:

session.upload_progress.enabled = 0

Or in an FPM pool (cannot be overridden by code):

php_admin_flag[session.upload_progress.enabled] = off

This is the same setting PHP recommended on 21 October as an interim mitigation for CVE-2026-109619 (part of PHP2Shell). If you already applied it, you don't need to do anything more for CVE-2026-115560.

Don't rely on ini_set() in application code or .user.ini files for this.

What is session upload progress, anyway?

It's a PHP feature that lets a website show a progress bar while a file uploads, by tracking the upload in the user's session. It's enabled by default but rarely used: most modern sites show upload progress with JavaScript in the browser instead.

Turning it off is unlikely to break anything. If your app genuinely uses PHP's session upload progress (you'd see session.upload_progress references or PHP_SESSION_UPLOAD_PROGRESS fields in forms), test before disabling, or switch to browser-side progress.

Has my host handled it?

• Hostinger disabled session.upload_progress across LiteSpeed, PHP Selector, cPanel PHP-FPM and phpMyAdmin on 21 October, and says non-VPS plans are already protected
• Wordify said it applied the mitigation and will apply PHP's fix when released
• Many other hosts applied the same setting for PHP2Shell

Check with your host if unsure. VPS and server owners need to set it themselves: VPS patching guide.

How to check the setting

• phpinfo(): search for session.upload_progress.enabled; it should show Off (how to create a temporary phpinfo page, and delete it afterwards)
• Command line (CLI config may differ from web): php -i | grep upload_progress

What to watch next

• PHP's next routine release for each supported branch, which should include the full fix and advisory
• Your host's announcements
• Further PHP2Shell variants: researchers said other untracked variants likely exist, which is another reason to stay on supported PHP versions with fast updates (end-of-life dates)

Where we fit

We keep PHP configuration, updates and security settings in order for the websites we build and maintain in Bangalore and Shivamogga. See website development.

Want someone to check your PHP settings? Get in touch.

Sources

• The Hacker News: PHP warns of another RCE risk two days after PHP2Shell
• Hostinger: Protections against php2shell
• Wordify: PHP security release, live updates