php2shell: What the Critical PHP Gap Teaches About Midsize Patch Management

On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities known as “php2shell”. The BSI warned on the same day, hosters worked through the night, some took services off the net as a precaution. For many companies, it was an involuntary exercise in patch management – and it showed where it is. This post summarizes what happened, how you check if you are affected, and what lessons can be learned for SMEs.

What happened

The two vulnerabilities CVE-2026-109618 and CVE-2026-109619 are at the core of PHP, i.e. in the language itself, not in a single application. They are classified as critical with a CVSS value of 9.2 and can, under certain conditions, allow attackers to run their own code on the server without logging on. This affects the usual operating modes in which PHP processes web requests – PHP-FPM, Apache with mod php, php-cgi, FrankenPHP and LiteSpeed.

The danger is the range: PHP runs on a large part of all web servers worldwide, under WordPress, shop systems, intranets and many specialist applications – and often also where you do not suspect it, for example in administration interfaces of NAS systems or firewalls. Accordingly, manufacturers such as Synology, QNAP or the providers of pfSense and OPNsense quickly followed suit with their own updates.

Am I affected?

The safe versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Everything below is vulnerable unless patched by the distributor. Three cases must be distinguished:

• Official PHP versions 8.2 to 8.5: Check if at least the mentioned version is running – and if the PHP service has been restarted afterwards. An installed update is of no use as long as the old process continues.
• PHP from the Linux distribution, for example with Ubuntu or Debian: The distributors build the fix into their own packages without raising the version number. Here only a look into the change log of the package, whether the two CVE numbers appear there.
• PHP 8.1 and older: These versions no longer receive updates from the PHP project. Those who operate them without distributor support have a problem that cannot be solved with an update, but only with a migration.

Important: Do not just check the version that uses your website. Many servers have several PHP versions in parallel – often including old ones that no one needs anymore, but which are still installed or even run as a service. And the administration interface of a hosting panel sometimes uses its own PHP installation.

Five lessons for SMEs

1. No patch without inventory

The first question in such a situation is: Where does PHP work at all for us? In many companies, no one could answer this immediately on October 21. Website, intranet, ticket system, basement time tracking, NAS, firewall interface – each of these systems is a potential entry point. A well-kept directory of your systems and the components used in them is the basis for any rapid reaction.

2. Speed is crucial

Between the release of a patch and the first automated attacks, critical gaps often only take hours. A patch cycle that takes effect once a month is not enough for such cases. You need a defined emergency process: Who evaluates the message, who decides, who patches – even in the evening or on weekends?

3. Clear responsibilities with service providers

Many companies have their website at an agency, hosting at a provider and the server at a third-party service provider. Who is responsible for the PHP update in an emergency? If this is not regulated in writing, everyone is waiting for the other. With managed hosting, usually the provider patches, with an own server or a virtual machine usually no one automatically.

4. Old versions are a permanent risk

Those who still use PHP 7.4 or 8.0 – often because an older application “only runs with it” – had no easy solution with php2shell. Such contaminated sites should not be tackled in an emergency. Unused versions are uninstalled, used versions are brought to a supported state. How to gradually modernize old applications without rebuilding everything, we describe in the contribution to loss-free migration during system change.

5. Bridging is not a solution

Web application firewalls, temporarily shutting down certain PHP functions or blocking access can bridge the time until the update. They do not replace the update. And after a critical incident, it also includes a look into the logs: Were there suspicious accesses, new or changed files in the time window before the patch?

Patch management becomes mandatory

What has been good practice so far is increasingly required by law. The NIS2 implementation obliges affected companies to handle vulnerabilities in an orderly manner. The Cyber Resilience Act requires manufacturers of digital products to provide security updates and actively report any gaps that have been exploited. And after that new product liability law from December, a missing security update can also trigger liability. Anyone who operates or offers software for customers should therefore be able to document their update process.

Checklist for the next critical gap

1. Directory of all systems with web components and their versions – including appliances such as NAS and firewalls.
2. Determined managers and representatives, even outside business hours.
3. Written responsibilities with hoster, agency and IT service provider.
4. A means of notification for security alerts, such as the BSI alerts.
5. A tested process for emergency updates, including restarting services and functional testing.
6. Regularly remove unneeded versions and services.
7. Logging that allows to detect suspicious activity afterwards.

Conclusion

php2shell was not the first critical gap in a basic technology, and it will not be the last. Companies that know their systems, have clarified responsibilities and have a well-established emergency process have survived the week with a few hours of extra effort. For everyone else, now is a good time to implement the lessons – before the next warning comes.

If you do not want to keep an eye on the operation of your servers and applications yourself, we take over this as part of our Managed Services from Stuttgart – with monitoring, fixed reaction times and documented patch management. Talk to us.