PHP Discloses Another Potential Remote Code Execution Vulnerability: CVE-2026–115560

Just two days after releasing emergency security updates for two critical PHP vulnerabilities, the PHP development team has disclosed another potential remote code execution (RCE) issue.

Tracked as CVE-2026–115560, the newly reported vulnerability involves PHP session handling and the session upload progress feature. Unlike the earlier PHP2Shell vulnerabilities, this issue affects a narrow combination of application code and configuration settings.

PHP considers the risk unlikely in typical deployments and has recommended a temporary configuration change rather than an emergency release. A permanent fix is expected in a future regular bugfix release.

For administrators responsible for PHP-based websites and production servers, this is another reason to review PHP security settings alongside routine software patching.

1. What is CVE-2026–115560?

CVE-2026–115560 is a potential remote code execution vulnerability associated with PHP's session serialization and upload progress mechanisms.

Session serialization determines how PHP converts session data into a format that can be stored and subsequently retrieved. Session upload progress allows applications to track the progress of file uploads.

Under an unusual combination of configuration settings and application behavior, PHP may handle internal state incorrectly, potentially creating a path to remote code execution.

The issue is not automatically exploitable on every PHP installation. PHP has specifically identified a narrow configuration sequence required for this reported vulnerability.

Official advisory: https://www.php.net/archive/2026.php#2026-10-23-1

2. Which configurations are potentially affected?

According to the PHP team's informational advisory, the application must meet all of the following conditions:

1. The configured session.serialize_handler is set to php_binary or php_serialize.
2. Application code changes this setting to php at runtime using ini_set().
3. This change occurs before the application calls session_start().
4. PHP session upload progress remains enabled.

The combination of these conditions creates the potential vulnerability.

Applications that do not change the session serialization handler at runtime are not exposed through this specific attack path, according to PHP's advisory.

This distinction matters: the disclosure does not mean every PHP website is directly vulnerable to CVE-2026–115560.

3. What impact could this vulnerability have?

If successfully exploited under the affected conditions, the issue could potentially allow remote code execution on the server.

Depending on the application's permissions and environment, possible consequences include:

• Server compromise: Execution of malicious code with the privileges of the PHP process.
• Application data exposure: Unauthorized access to files, configuration data, or credentials available to the application.
• Website disruption: Changes to application behavior or interruption of services.
• Further compromise: Use of an affected application as an entry point for additional attacks.

These are potential impacts of successful exploitation, not evidence that every affected configuration will lead to complete server compromise.

As of the October 23 advisory, PHP had not reported exploitation of CVE-2026–115560 in the wild.

4. Does the previous PHP security update fix this issue?

No. The October 21 PHP2Shell security updates do not, by themselves, resolve CVE-2026–115560.

The previous emergency releases addressed two separate vulnerabilities:

• CVE-2026–109618
• CVE-2026–109619

The corresponding upstream patched releases were PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

The new issue is separate, and PHP has not yet published a full advisory specifying all affected versions or the exact releases containing its permanent fix.

Administrators should therefore keep their PHP installations updated while applying the recommended temporary mitigation for the new issue.

5. How to mitigate CVE-2026–115560

PHP recommends disabling session upload progress until a fix becomes available in a regular bugfix release.

The configuration directive is:

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

This disables PHP's session upload progress functionality. Applications that rely on this feature to display upload progress may lose that functionality, so test the change against application requirements.

A. Ubuntu and Debian servers

Identify the active PHP configuration for the web application. On a typical PHP 8.4 installation using PHP-FPM, the configuration file is:

/etc/php/8.4/fpm/php.ini

/etc/php/8.4/fpm/php.ini

Edit the file:

sudo nano /etc/php/8.4/fpm/php.ini

sudo nano /etc/php/8.4/fpm/php.ini

Set the following directive:

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

Then restart PHP-FPM:

sudo systemctl restart php8.4-fpm

sudo systemctl restart php8.4-fpm

If Apache uses mod_php rather than PHP-FPM, configure the directive in the active Apache PHP configuration instead and restart Apache.

If the server uses NGINX with PHP-FPM, restarting NGINX is generally not necessary for this PHP configuration change; restart the relevant PHP-FPM service.

B. RHEL-based servers

For RHEL, AlmaLinux, Rocky Linux, and similar distributions, identify the active PHP configuration file. A typical PHP-FPM installation uses:

/etc/php.ini

/etc/php.ini

Edit the configuration:

sudo nano /etc/php.ini

sudo nano /etc/php.ini

Set:

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

Restart PHP-FPM:

sudo systemctl restart php-fpm

sudo systemctl restart php-fpm

Restart or reload the web server only if required by the configuration change or deployment method.

Note: PHP installed through Remi Software Collections, cPanel/EasyApache, or a custom build may use a different configuration file and service name.

C. Windows Server

For a Windows Server installation, locate the php.ini file used by the active PHP runtime.

Add or update:

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

Save the file and restart the relevant IIS application pool or web server service so the configuration is applied to the active PHP workers.

For IIS FastCGI deployments, confirm that the website is using the PHP installation whose configuration you edited.

D. Docker and Kubernetes deployments

If PHP runs inside Docker containers or Kubernetes workloads, update the PHP configuration used by the container.

For example, add the directive to the appropriate PHP configuration file:

session.upload_progress.enabled = Off

session.upload_progress.enabled = Off

Rebuild or update the image or configuration according to your deployment process, roll out the updated workloads, and verify that every active PHP worker has the setting disabled.

Changing PHP configuration on the container host does not automatically change the configuration inside running containers.

6. Important verification steps

After applying the mitigation, verify that the setting is disabled in the PHP runtime serving the application.

For command-line PHP, you can run:

php -i | grep session.upload_progress.enabled

php -i | grep session.upload_progress.enabled

On Windows PowerShell:

php -i | Select-String "session.upload_progress.enabled"

php -i | Select-String "session.upload_progress.enabled"

The output should indicate that the setting is disabled.

However, CLI verification alone is not sufficient. The command-line PHP configuration may differ from PHP-FPM, Apache, IIS, or a hosting control panel's active configuration.

Verify the effective setting for the actual web runtime using an appropriately restricted diagnostic method. Restart the relevant PHP workers and confirm the configuration has taken effect.

For PHP-FPM environments where an administrator-level setting is appropriate, the pool configuration can enforce the setting:

php_admin_flag[session.upload_progress.enabled] = off

php_admin_flag[session.upload_progress.enabled] = off

Place this in the relevant FPM pool configuration and restart the corresponding PHP-FPM service.

Avoid relying on application-level ini_set() calls or .user.ini for this mitigation because the setting must take effect before the vulnerable request-processing path.

7. Does disabling session upload progress replace PHP patching?

No.

Disabling session.upload_progress.enabled is a temporary mitigation for the reported issue, not a permanent code fix. It may also affect applications that rely on upload progress indicators.

Administrators should:

• Keep PHP updated to the latest applicable security release.
• Apply the temporary configuration mitigation.
• Review application code for runtime changes to session.serialize_handler.
• Confirm the setting is disabled in every relevant PHP runtime.
• Monitor official PHP releases for the permanent fix.
• Test application functionality after making configuration changes.

The PHP team plans to publish a full advisory alongside the regular release containing the fix.

8. Security checklist for administrators

• Confirm that the earlier PHP2Shell security updates have been applied.
• Set session.upload_progress.enabled = Off in the applicable PHP configuration.
• Restart all relevant PHP workers or redeploy affected containers.
• Verify the effective configuration used by each website.
• Review application code for changes to session.serialize_handler.
• Test file-upload workflows and application functionality.
• Monitor the official PHP advisory and subsequent releases.
• Apply the permanent fix when it becomes available.

Conclusion

CVE-2026–115560 is a newly disclosed PHP security issue involving session serialization and upload progress handling. Its reported impact depends on an unusual combination of configuration and application behavior, and PHP has not reported exploitation of this specific issue.

The recommended immediate action is straightforward: disable session upload progress, verify the change in the active PHP runtime, and continue monitoring PHP's official security updates for the permanent fix.

The broader lesson is that security maintenance does not end when an emergency patch is installed. Configuration reviews, runtime verification, and ongoing vulnerability monitoring remain important parts of maintaining secure production infrastructure.

Official reference: https://www.php.net/archive/2026.php#2026-10-23-1

Disclaimer: The commands and configuration examples in this article are illustrative. Validate the active PHP configuration, deployment method, and application compatibility before applying changes to production systems.