PHP2Shell Follow-up: Do You Need to Change Your Session Settings?

If you already updated PHP after PHP2Shell, there is one more notice to review. On 23 October, the PHP team described an additional risk involving session upload progress and a particular way of changing session settings.

The notice does not say every PHP application is affected. The first thing to check is whether your application changes its session serializer while handling a request.

What does that mean in ordinary PHP code?

A session lets PHP keep information between requests, such as the data associated with a signed-in user. The session serializer controls how that data is encoded when PHP stores it.

PHP also has an upload-progress feature that can store information about an upload in the session. An application can use this to report how much of a file has arrived.

The new notice concerns a combination of these features. PHP describes a possible remote-code-execution issue, meaning an attacker could potentially make the server execute code. The issue is tracked as CVE-2026-115560.

Which combination should I look for?

The PHP notice describes an application that:

1. Starts with session.serialize_handler set to php_binary or php_serialize.
2. Changes that setting to php using ini_set() before calling session_start().
3. Still has session upload progress enabled.

Read those as a combination. Seeing session_start() in your project alone does not establish that the application matches the notice.

Search your application and relevant dependencies for session.serialize_handler, then inspect any code that changes it. Check the PHP configuration used by the web application as well. Your command-line PHP installation may use a different configuration.

If someone else manages the server, send them the official notice and ask them to check these settings in the environment serving your site.

What does PHP recommend?

PHP suggests disabling session upload progress until the next regular bugfix release:

session.upload_progress.enabled=0

There are two qualifications in the notice:

• Applications that never change the serializer at runtime can keep the feature enabled.
• If you already applied this setting for the earlier CVE-2026-109619 advisory, keep it in place. PHP says no further action is needed for that case.

Source: PHP’s 23 October informational advisory.

What should I check after changing the setting?

If you need to apply the setting, have the person responsible for the deployment put it in php.ini, an FPM pool or server configuration that applies before request parsing, then restart every relevant PHP worker. Do not rely on ini_set() or FPM .user.ini for this mitigation. These deployment instructions come from PHP’s 21 October security advisory. Then confirm the effective setting in the web-serving environment.

Test any upload-progress interface your application uses, because disabling the feature can affect how progress is reported. Also run your usual session and upload checks after the configuration change.

Record where the setting was changed and which application instances received it. That avoids assuming that a configuration edit reached every running worker.

Do I still need the original PHP2Shell update?

Yes. Keep the original fixes and any applicable mitigation in place. This follow-up adds a configuration check; it does not replace the previous patch guidance.

Our original PHP2Shell article covers CVE-2026-109618 and CVE-2026-109619. Keep that update record together with the outcome of this session-setting review.

What is still pending?

PHP says a full advisory will accompany the next release. This preliminary notice does not provide a complete account of affected builds or exploit conditions.

For now, write down whether your application changes its serializer, whether upload progress is enabled, and which guidance you followed. Revisit that record when PHP publishes the full advisory and release.

Checked 24 October 2026 against PHP’s official notices. TechWebster has not independently reproduced the issue.