Fixing PHP2Shell: Turning an installed update into effective protection

An update is only the beginning

A critical vulnerability calls for a quick response. But starting an arbitrary update and assuming the job is done is not enough.

Corrected PHP releases, or appropriately patched vendor packages, fix CVE-2026-109618 and CVE-2026-109619. Configuration changes may obstruct particular attack paths, but they do not replace the complete fix. [1][2]

The essential distinction is this: a patched package must not merely be present on the server. The application must actually be using the patched runtime.

Which official PHP releases contain the fixes?

At the research date, the minimum corrected releases in the PHP project's supported release branches are:

This table refers to the PHP project's unmodified releases. Linux distributions and managed vendor packages may deliver the fixes under a different full package version. [1][3]

An application using PHP 8.3 does not necessarily need an immediate major move to PHP 8.5. First check for the security fix within the supported branch already in use.

I would not combine an emergency fix with a wholesale application modernisation without a specific reason.

1. Identify every PHP installation actually in use

A server can contain several PHP versions, as well as containers, hosting-panel packages and runtimes embedded in other products.

In its analysis of 21 October 2026, Qualys explicitly notes that php -v may report a different installation from the one handling web requests. [3]

For administrators, these commands provide a first, read-only check: php -v and php --ini.

They show the version of the PHP executable being invoked and its loaded configuration files. They do not, on their own, establish which version a particular website or an already-running background process uses. The options are documented in the PHP manual. [4]

I would map every production website to its actual PHP handler, service or container. Test sites and old subdomains belong in that inventory too if they are still accessible.

2. Temporarily isolate systems that cannot be patched promptly

If an exposed system cannot be updated promptly, CERT-EU recommends considering temporary isolation from public networks until the fix has been installed and verified. [2]

A maintenance mode inside the CMS is not a reliable substitute. With Apache mod_php, a confirmed attack path can begin before application code runs. Protection must therefore take effect before the vulnerable PHP processing. [5]

In practice, I would consider a static maintenance page outside the affected PHP application, or controlled access restrictions at an upstream layer.

The administrator must choose an appropriate method for the environment. An ordinary website owner should not change firewall rules on a hunch and risk blocking other services.

3. Use the correct update channel

For hosted websites, the provider is responsible where it manages the PHP runtime. On a self-managed server, use the package source or management procedure intended for that platform.

The full package version matters, not just the short PHP number.

For example, Ubuntu lists 8.3.6-0ubuntu0.24.04.13 as corrected for Ubuntu 24.04 LTS. Although the number still includes 8.3.6, that Ubuntu package contains the security fixes. Judging it solely against the upstream release table would be wrong. [6]

I would compare the installed package identifier with the security advisory for the distribution actually in use. An arbitrary version comparison from a forum is not enough.

Plesk also describes cases where corrected older PHP releases retain their PHP version number but receive a new build. It distinguishes website PHP installations from sw-engine, the internal PHP component used by its management interface. That component's fix must be checked separately against Plesk's current advisory; an updated website handler is not evidence that sw-engine has been fixed. [7]

4. Prepare a backup and recovery route without delaying the patch unnecessarily

Before making changes, I would preserve or check the current configuration, required data and the intended recovery procedure.

That must not leave a vulnerable public system exposed for hours while an elaborate rehearsal is arranged. Where necessary, restrict access first.

If an attack is already suspected, preserve logs and relevant system state and involve qualified support. A newly created backup is not automatically a demonstrably clean recovery point.

Recovery needs a boundary too: after an unsuccessful update, an unpatched old version must not simply be made public again. Restoration must include an effective fix or continued isolation.

5. Refresh running services and background processes

After the package update, check which processes still have the old runtime loaded in memory.

Laravel Forge explicitly warns that long-running PHP processes can continue using the previous version after a package update. Queue workers and persistent application services are examples. They need separate restarts. [8]

Depending on the deployment, this may involve PHP-FPM, a web server with embedded PHP, application services or redeploying containers.

I would not merely restart a container whose image still contains unpatched software. First the corrected software must be included in the image being deployed. Qualys also explicitly calls for updating or rebuilding images and replacing running instances. [3]

Evidence of completion must therefore cover the running system, not just the package manager's success message.

6. Do not confuse emergency settings with a complete fix

Various temporary measures are being discussed online. Some do come from the official guidance, but cover only particular variants.

Examples include disabling upload-progress processing with session.upload_progress.enabled=0 and disabling certain error backtraces in PHP 8.5. These settings must take effect before request processing; changing them only inside application code is insufficient for the described protections. [5]

Take particular care with memory_limit=-1. It removes PHP's own memory limit. It may obstruct one fault path, but leaves other risks and may facilitate resource exhaustion. It is not a setting to copy indiscriminately. [3][5]

For ordinary operators, the corrected PHP software is the right route. Temporary configuration changes belong with the responsible administrator.

Once the fix is verified, reassess temporary restrictions and reverse them in a controlled way where appropriate. In particular, restore a suitable finite memory limit if it was temporarily removed. Functional testing should also cover behaviour when memory runs out. [3]

7. Check functionality and security separately

After the update, I would test a few important workflows: page loading, sign-in, form handling, required uploads and essential background jobs.

That tells you whether the application still works. It does not replace evidence that every PHP instance in use has been fixed.

Record the package version, update time, refreshed services and result for each affected application. Remove or permanently retire installations that are no longer required rather than leaving them unnoticed for possible future use.

What else is needed if an intrusion is suspected?

An update closes the vulnerability. It does not automatically remove a backdoor installed earlier.

The NCSC explicitly recommends looking for evidence of compromise and installed backdoors on systems that were not patched or taken offline promptly. Where the necessary expertise is unavailable, bring in specialist support. [9]

Which credentials need replacing and which systems need restoring depends on the findings. Where there is a concrete suspicion of attack, a successful package update is not sufficient grounds for an all-clear.

My conclusion: The job is not finished until the result is checked

An effective response is not about making as many changes as possible. It is about making the right changes in the right places.

Identify the affected application, install the appropriate patch, refresh running processes and verify the result. Only that complete chain turns an update notification into a completed security measure.

Scope of this article

This is general guidance. Package names, management procedures and restart requirements vary between operating systems and hosting environments. Qualified people responsible for the systems must make production changes. These notes do not replace an individual operational plan or an investigation into a possible intrusion.

Sources and further reading

Research date: 21 October 2026. Vendor statements and published investigations are not our own technical assessment of the systems described.

[1] PHP project: security releases of 21 October 2026
Read source ↗

[2] CERT-EU: patching and temporary isolation
Read source ↗

[3] Qualys: running instances, update verification and mitigation limits
Read source ↗

[4] PHP manual: command-line options
Read source ↗

[5] PHP security advisories: temporary mitigation boundaries
Read source ↗

[5] PHP security advisories: temporary mitigation boundaries
Read source ↗

[6] Ubuntu: security notice USN-8948-1
Read source ↗

[7] Plesk: affected components, corrected packages and builds
Read source ↗

[8] Laravel Forge: PHP updates and long-running processes
Read source ↗

[9] NCSC: priorities and investigation of potential compromise
Read source ↗

More articles in this series

PHP2Shell · Part 1
Read source ↗

PHP2Shell · Part 3
Read source ↗