On October 21, 2026, the PHP Project patched two critical PHP security vulnerabilities known as PHP2Shell. For website operators, everything came down to one question that day: Can the update be installed or not? Those who had previously invested regularly in updates for their application could answer “yes.” For our customers, that investment paid off that day: They could breathe a sigh of relief, because we took care of everything else. For everyone else, the only choice was between taking the site offline and accepting the residual risk.
What Happened
PHP is the programming language on which a large portion of all websites run, including systems like Pimcore, Shopware, and WordPress. In the worst-case scenario, these two vulnerabilities allow arbitrary code to be executed on the server without requiring authentication. Anyone exploiting this could potentially gain full access to the application and its data, including sensitive customer and payment information. Attackers could also potentially gain access to the interfaces to connected systems, such as inventory management or payment service providers. According to the security firm Wiz, which discovered the vulnerabilities, all PHP versions from the past 10 years are affected.
On October 20, the PHP team announced a security update for the following day at 4:00 p.m. CEST, without providing any details. The first unofficial reports began circulating that same day. Germany’s Federal Office for Information Security (BSI) issued a warning at the second-highest alert level and advised temporarily taking systems offline if in doubt. As a result, some government agencies, universities, and hospitals temporarily took their websites offline. Many other sites were also temporarily unavailable.
As of the evening of October 21, no successful attacks had been publicly confirmed. However, security firms reported initial attack attempts.
How We Proceeded
As is customary in such cases, the initial announcement contained no details. The only thing that was clear was that there was a critical security vulnerability, and that the update scheduled for the following day would patch it. Exactly what the vulnerability entailed and whether there were any other effective protective measures available until then remained unclear.
According to unofficial information, exploiting the vulnerability could be prevented – or at least made more difficult – by changing the system configuration. As a precaution, we made this change on all customer systems. It later turned out that while this reduced the risk, it did not completely close the vulnerability.
With the official update, we secured all systems running PHP 8.2 or newer. For these websites, the issue was resolved, and they continued to run without interruption.
The situation is different for systems running older PHP versions, for which the PHP project no longer officially provides updates. Normally, switching to a newer, secure PHP version would be the right course of action here. However, if the outdated application does not support this, there is only one option: a precautionary shutdown. We informed our customers about this step via email and by phone.
However, due to the severity of the vulnerabilities, the PHP team made an exception and released an emergency patch for some older versions. A stroke of luck: Without it, the only solution would have been to update the entire application, including the PHP version. That cannot be done in a few hours, and the affected sites would have faced an indefinite shutdown.
Why Updates Aren’t an End in Themselves
There was about one day between the initial announcement and the official update. For a current system, that’s sufficient, since the update is a routine task. For an outdated system, it’s not enough. A new PHP version requires that the application also support it – whether Pimcore, Shopware, or a custom-built application. If the application is too old, the first step is to update Pimcore, Shopware, or the custom-built application: a separate project involving planning, customizations, and testing. In an emergency, that’s too much to get done in time.
Updates have a visibility problem: they don’t always introduce new features, and the website often looks the same afterward. It’s therefore easy to understand why new features often take priority in day-to-day operations. Their value only becomes apparent on a day like October 21: the ability to patch a security vulnerability in the shortest possible time, rather than taking the website offline. And a well-maintained platform is one that you can continue to develop, rather than just managing emergencies.
For us, regular maintenance consists of two parts. We apply minor updates on an ongoing basis, using a monthly hour allocation for maintenance and updates as part of an agency service agreement. We plan major version upgrades – such as a move to a new version of Pimcore Platform – together with you as a separate project, well in advance of when the old version loses support. You can read more about our development work under Build.
The next deadline has already been set: PHP 8.2 will no longer receive security updates as of December 31, 2026. Systems that were still able to receive updates without any issues on October 21 will then be in the same position as older systems were on that day. Those who plan now still have a good two months to prepare.
Why Many of Our Customers Stayed Online
Our hosting customers’ Pimcore and Shopware platforms run on our own infrastructure – a Kubernetes cluster in European data centers. We handle all operations there, including security updates for PHP. So when a vulnerability like PHP2Shell arises, our customers don’t have to take action themselves. We provide the patched versions and deploy them without taking the website offline. For many of the websites we host, this ensured uninterrupted operation on October 21, while elsewhere sites were taken offline as a precaution.
The limit is reached when the application itself is too old. In that case, even the best operations team has no choice but to shut it down. That’s why, for us, operations and maintenance go hand in hand. You can read about how we operate platforms under Run.
How Up-to-Date Is Your Platform?
If you’d like to know where your system stands after October 21, we’d be happy to talk with you. During our conversation, we’ll review your platform’s update status together. We’ll clarify what needs to be done before PHP 8.2 reaches end-of-support and discuss what ongoing maintenance might look like for you.
