PHP CVE-2026-115560: A Narrow Session RCE Path and the Mitigation to Apply Now

There is a new PHP security notice. That does not mean every PHP website has a new remotely exploitable flaw.

On 23 October 2026, PHP published an informational advisory about CVE-2026-115560, a possible remote-code-execution path involving session upload progress. The important part is the conjunction of configuration and application behavior required to reach it—not just the letters “RCE” in a headline. [1][5]

Last checked: 23 October 2026, Asia/Beirut. This article explains the official mitigation and what remains unknown. The notice date is not proof that the issue was first discovered that day.

The issue level: serious impact, narrow exposure

The possible impact is remote code execution (RCE). PHP describes the scenario as unlikely in practice and is handling it through the regular release cycle, rather than announcing another emergency release. Its informational notice does not give a numeric CVSS score or a complete affected-version matrix. Do not copy the earlier PHP2Shell “Critical” classification or score onto this separate CVE. [1]

That is not a reason to ignore the notice. It is a reason to act precisely:

• If your application meets the described conditions: apply the official mitigation now and verify the running web environment.
• If you have not established whether those conditions occur: review the configuration and bootstrap/dependency code; consider the recommended disablement while investigating, after checking feature dependencies.
• If the application never changes its session serialization handler at runtime: PHP explicitly says it can keep session upload progress enabled. The feature being enabled by itself does not establish exposure to this path. [1]

The sources reviewed here do not establish widespread exploitation of this specific new CVE. Reports about the older PHP2Shell flaws should not be silently attributed to it.

All three conditions must coincide

PHP describes this combination: [1]

1. Initial configuration: session.serialize_handler is set to php_binary or php_serialize.
2. Runtime change: application code switches that setting to php using ini_set(), before calling session_start().
3. Feature still on: session.upload_progress.enabled remains enabled.

An application which uses php throughout is not the same as one which switches from another handler to php. Likewise, merely using sessions, accepting file uploads, or running a particular framework does not demonstrate all the conditions above.

Review application initialization, session wrappers, plugins and relevant dependencies—not just one controller. A framework name alone is not an affectedness assessment.

The immediate official mitigation

Set the following administratively, in the effective configuration used by the PHP web runtime:

session.upload_progress.enabled=0

PHP recommends keeping this setting until the next regular bugfix release. If you already applied it after the 21 October advisory and it remains effective, PHP says no further action is needed for this new vector. [1]

A practical completion checklist:

1. Identify the PHP configuration actually loaded by each web SAPI, FPM pool and container.
2. Apply the setting at the appropriate configuration level and check for conflicting overrides.
3. Restart the relevant PHP-FPM workers or Apache PHP processes through your normal service-management procedure.
4. Verify the value in the running web application, including all replicas.
5. Test any application feature that depends on PHP’s session-based upload-progress mechanism.

The earlier official session-lifecycle mitigation also explicitly says to apply the setting administratively and restart every worker. A successful configuration edit is not evidence that the already-running workers received it. [2]

Do not rely on a controller-level ini_set()

The PHP manual lists session.upload_progress.enabled as INI_PERDIR, with a default value of "1". It is not a setting you can reliably switch off with an ordinary runtime ini_set() in a route/controller. Its administrative configuration must be addressed. [3]

Be careful not to confuse the two directives: the vulnerable scenario involves runtime changes to session.serialize_handler; the recommended mitigation disables session.upload_progress.enabled.

How to verify without confusing CLI and web PHP

CLI PHP may load a different configuration from PHP-FPM or Apache. Therefore, a passing php -i check in your shell is not sufficient to close the task for the website.

Use an existing authenticated administrative diagnostic or a controlled internal check in the actual web runtime. The following is a read-only inventory aid, not a vulnerability scanner or an exploit:

<?php
// Run only through a controlled internal/authenticated diagnostic.
// Do not expose this as a permanent public endpoint.
header('Content-Type: application/json; charset=utf-8');

echo json_encode([
    'php_version' => PHP_VERSION,
    'sapi' => PHP_SAPI,
    'upload_progress_enabled' => (bool) ini_get('session.upload_progress.enabled'),
    'current_serialize_handler' => ini_get('session.serialize_handler'),
]);

After applying the mitigation, upload_progress_enabled should be false in each relevant web runtime. Remove a temporary diagnostic after use and do not publish a full phpinfo() page.

This check has limits: the current serialization handler does not show its complete history during initialization. Source review is still necessary to establish whether a handler transition occurred, and a diagnostic from one replica does not verify every replica.

Will this stop ordinary file uploads?

The setting controls PHP’s session upload-progress tracking, which populates progress information in the session. It is not the general switch for accepting file uploads. Disabling it is therefore not the same as disabling normal uploads. However, progress indicators or cancellation logic relying on that particular PHP feature may need application testing. [4]

Do not assume every browser upload progress bar uses this mechanism; check the implementation in your application.

How this differs from the 21 October PHP2Shell updates

The earlier PHP2Shell issues were CVE-2026-109618 and CVE-2026-109619. Their emergency corrected releases included PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Those updates remain important, but installing them alone does not close the new path described in today’s notice. [2][5]

The overlap is the mitigation: disabling session upload progress was already recommended for the session-related path in the earlier advisory. The new PHP notice explicitly tells administrators who applied it to keep it in place. [1][2]

Do both where applicable: keep the earlier security patches, and apply or retain the new notice’s recommended configuration mitigation. Disabling upload progress is not a replacement for the broader PHP2Shell fixes; the earlier advisory says it does not cover other lifecycle paths. [2]

For the earlier release instructions and legacy-version boundaries, see our PHP2Shell patching guide.

What is not confirmed yet

At the time of verification, the official informational notice promises a full CVE-2026-115560 advisory with the next release. It does not provide a full affected-version matrix, a new numeric severity score, a fixed-version list for this CVE, or a specific release date. [1]

Avoid these unsupported shortcuts:

• “Every PHP website is vulnerable.”
• “The earlier PHP2Shell update fixes this too.”
• “This new CVE has the same score as the older CVEs.”
• “A framework is safe or vulnerable just because of its name.”
• “The setting was changed in CLI, so all web workers are protected.”

Bottom line

New notice, narrow prerequisites, immediate mitigation. Review the session configuration and runtime transitions, disable PHP session upload progress where appropriate, restart and verify the web workers, and retain the earlier security patches. Follow PHP’s next regular release for the final fix and full advisory. [1][2]

Sources

[1] https://www.php.net/archive/2026.php — Official informational notice, 23 October 2026.

[2] https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp — Earlier session-lifecycle advisory, corrected versions and administrative mitigation.

[3] https://www.php.net/manual/en/session.configuration.php — Directive defaults and changeability.

[4] https://www.php.net/manual/en/session.upload-progress.php — What session upload-progress tracking actually does.

[5] https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html — Reporting on the new notice and its distinction from PHP2Shell.