PHP Discloses Another Unpatched RCE Flaw Days After Emergency PHP2Shell Updates

Just as system administrators were finishing emergency patch rollouts for the critical PHP2Shell vulnerabilities, the PHP development team released another security advisory. A newly identified remote code execution flaw remains unpatched in the current engine, requiring immediate configuration reviews across web infrastructure.

Today is October 24, 2026. Over the past seventy-two hours, security teams have been racing to patch two critical flaws disclosed on October 21. Now, tracked as CVE-2026-115560, this new disclosure introduces an additional attack surface that emergency updates did not cover. If you run PHP in production across servers, containers, or shared hosting, understanding how this flaw works and applying the recommended mitigations is essential.

What Is CVE-2026-115560?

The newly disclosed issue involves PHP's session upload progress mechanism and runtime adjustments to session configuration.

When users upload files, PHP can track transfer progress in real time through a built-in feature called session upload progress. When enabled, PHP intercepts incoming file transfers and writes progress data directly into the user's session before the application script executes.

Under standard conditions, this feature operates safely. However, the vulnerability emerges when an application alters its session serialization handler dynamically during execution. A serialization handler determines how PHP encodes and decodes arrays and objects for storage, supporting formats like php (the default), php_binary, and php_serialize.

According to the official security notice, CVE-2026-115560 requires three specific conditions to coincide:

1. The server initially configures session.serialize_handler as either php_binary or php_serialize.
2. The application changes that setting to php using ini_set() during execution, before calling session_start().
3. Session upload progress remains enabled on the server.

Because PHP writes upload tracking data using the initial handler before script execution, switching handlers dynamically causes a severe serialization mismatch when the session opens. This allows an attacker to supply crafted input that triggers memory corruption and remote code execution when deserialized.

How This Differs from the Earlier PHP2Shell Vulnerabilities

CVE-2026-115560 is not a failure of the emergency updates released on October 21. Those updates addressed two separate, critical flaws collectively nicknamed PHP2Shell.

To evaluate your exposure, you must distinguish between these three distinct issues:

1. CVE-2026-109618: Out-of-Memory Cleanup RCE

This vulnerability occurs when PHP encounters memory exhaustion during request handling. If memory runs out while request data structures are partially initialized, PHP interrupts execution to clean up resources. During cleanup, the runtime processes invalid memory states, allowing attackers to achieve remote code execution under the web worker account (notably under Apache mod_php). Updating your PHP binary is the only complete fix.

2. CVE-2026-109619: Stale State and Use-After-Free

This issue stems from worker process reuse across HTTP requests in persistent environments like PHP-FPM. When a worker frees memory from an earlier request but fails to reset internal pointers, a subsequent request processed by that same worker can access stale memory. This produces a use-after-free condition. While upload progress was one trigger mechanism, the underlying bug extends across several runtime paths.

3. CVE-2026-115560: Runtime Handler Deserialization

Unlike the earlier memory corruption bugs, this flaw depends on application bootstrap logic altering session formats mid-flight. Because an official patch will arrive during the regular release cycle, administrators cannot rely on the October 21 binaries alone to protect their systems.

The Evidence of Prior Exploitation: Audit Back to October 17

While PHP stated that no active exploitation of CVE-2026-115560 had been documented prior to disclosure, the earlier PHP2Shell vulnerabilities were actively probed in the wild.

Amazon threat researchers reported that their MadPot honeypot network captured exploit attempts targeting PHP2Shell on October 17, four full days before the public disclosure and emergency patches. The traffic originated from commercial anonymization networks.

This intelligence has immediate operational consequences:

• Applying patches secures systems against future attacks, but it does not tell you if an intrusion already occurred.
• Any forensic review of access logs, file modifications, or anomalous process executions must extend back to at least October 17, 2026, rather than starting on the disclosure date.

Step-by-Step Mitigation and Hardening Guide

Because an official engine patch for CVE-2026-115560 is still being prepared, administrators must apply configuration mitigations immediately while completing their rollout of the October 21 updates.

Step 1: Disable Session Upload Progress in php.ini

Disabling upload progress closes the attack path for CVE-2026-115560 without disabling standard file uploads. Standard uploads continue functioning normally; only PHP's internal session tracker is disabled.

Set the directive to 0 in your active php.ini or FPM pool configuration:

; Disable PHP session upload progress tracking
session.upload_progress.enabled = 0

Verify the setting across active configuration files:

# Check if session upload progress is enabled
php -i | grep -E "session.upload_progress.enabled"

If the command returns session.upload_progress.enabled => Off => Off, the mitigation is active.

Step 2: Restart PHP-FPM and Web Server Daemons

PHP reads configuration directives when worker processes spawn. Editing php.ini has no effect on running workers until they restart.

Restart your PHP processing services:

# For systems running PHP-FPM with systemd
sudo systemctl restart php*-fpm

# For systems running Apache with mod_php
sudo systemctl restart apache2 || sudo systemctl restart httpd

# Verify that worker processes refreshed their start times
ps -eo pid,lstart,cmd | grep -E "php-fpm|apache2|httpd" | grep -v grep

Step 3: Audit Application Code for Runtime Handler Switches

The vulnerability requires an application to switch session.serialize_handler at runtime using ini_set(). Scan your codebase to verify whether application code or installed vendor libraries perform this switch:

# Search for runtime serialization handler changes
grep -rn "session.serialize_handler" /var/www/html/ 2>/dev/null

If your search returns no instances of ini_set('session.serialize_handler', ...), your application does not invoke the vulnerable runtime transition. If vendor libraries require a specific handler, configure it statically in php.ini instead of dynamically before session_start().

Step 4: Inspect System and Web Logs from October 17 Onward

To ensure systems were not targeted during the zero-day window identified by honeypot data, audit your web logs:

# Check web server logs for suspicious session upload parameters
sudo zgrep -E "PHP_SESSION_UPLOAD_PROGRESS|php_serialize" /var/log/nginx/*access.log* /var/log/apache2/*access.log* 2>/dev/null | head -n 30

# Check for unexpected PHP files created since October 17
sudo find /var/www/html/ -type f -newermt "2026-10-17" -name "*.php" -ls

Examine any unverified PHP scripts or unexpected background processes spawned by web worker accounts.

Conclusion

The disclosure of CVE-2026-115560 reinforces an essential security lesson: software patching and configuration hardening must work together. While teams must finish deploying the October 21 emergency patches to resolve the PHP2Shell memory bugs, disabling session upload progress provides an immediate safeguard against this newest RCE attack vector. Taking both steps ensures your web infrastructure remains resilient until the upstream bugfix release arrives.

Merits

• Disabling session upload progress provides immediate protection without waiting for recompiled binaries.
• Standard file uploads continue functioning normally, preserving core application features.
• Reduces overall attack surface by eliminating an unnecessary legacy session hook.
• Auditing logs back to October 17 detects pre-disclosure probing and potential web shell drops.
• Promotes static, deterministic session configuration over risky runtime environment changes.

Demerits

• Disabling upload progress breaks custom UI progress bars that query PHP's internal session array.
• Requires coordinating configuration changes and daemon restarts across distributed server fleets.
• Configuration mitigations do not address underlying memory bugs, leaving emergency updates mandatory.
• Identifying dynamic ini_set calls inside obfuscated vendor packages requires dedicated code audits.

Caution

This article is for educational purposes only. System commands, configuration directives, and file paths must be adapted to your specific Linux distribution, PHP version, and hosting architecture. Always test configuration changes in a staging environment and verify security advisories with upstream project maintainers before modifying production infrastructure.

Frequently asked questions

• What is CVE-2026-115560? — It is a newly disclosed remote code execution vulnerability in PHP caused by a mismatch between session upload progress and runtime changes to session serialization handlers.
• Is CVE-2026-115560 patched in the latest PHP releases? — No, the flaw remains unpatched in current builds, and the PHP project plans to deliver an official fix in its next regular release cycle.
• How can administrators protect servers right now? — Administrators should set session.upload_progress.enabled = 0 in their php.ini files and restart all PHP worker services.
• Does disabling upload progress prevent users from uploading files? — No, standard file uploads through HTTP POST continue working normally; only PHP's internal real-time session progress tracker is disabled.
• Does the new flaw affect systems that installed the October 21 emergency updates? — Yes, the October 21 updates fixed the earlier PHP2Shell memory flaws, but CVE-2026-115560 is a separate issue that requires configuration mitigation.
• Why are security teams investigating activity back to October 17? — Threat intelligence from Amazon's MadPot network observed exploitation probes targeting PHP2Shell four days before public disclosure, widening the required review window.
• What conditions are required to exploit CVE-2026-115560? — The application must start with a non-standard serialization handler, change it to php via ini_set() before session_start(), and have session upload progress enabled.

Tags

#php #cve2026115560 #php2shell #cybersecurity #vulnerability #infosec #sysadmin #devops #websecurity #patchmanagement