What a week… even friends and family who have nothing to do with IT asked us how we managed to get through it. What happened?
Last Wednesday, the PHP project released security updates for two critical vulnerabilities that made headlines under the name “php2shell.” That day, government agencies, hospitals, and even some web hosting providers took their websites offline as a precaution. The fact that we kept our projects online requires an explanation. And we’d also like to share what we’ve learned from these intense days.
What is php2shell all about?
The two vulnerabilities (CVE-2026-109618 and CVE-2026-109619) lie deep within the core of PHP, in its memory management and error handling. Under certain conditions, they allow an attacker to execute code on the server without logging in. Virtually all PHP versions released in recent years were affected, regardless of which CMS or framework they were running on. Both vulnerabilities were classified as critical with a CVSS score of 9.2.
Although this release had been planned for a very long time and, above all, kept secret, things became somewhat hectic in the end. The PHP Foundation described this openly in its post about the release. The release was scheduled for 22 October. However, as early as the afternoon of 20 October, the CVE numbers appeared online, followed shortly afterwards by a video demonstrating a working proof of concept. On the morning of 21 October, a provider of container images released the fix, more than six hours ahead of the coordinated release time. The PHP team therefore brought the release forward to 4.00 pm (CEST) on 21 October.
How 21 October went for us
For Flownative Beach, we build our own PHP images directly from the source code. Whilst this involves a bit more work on a day-to-day basis, it paid off on this particular day: we didn’t have to wait for Linux distributions to make ready-made packages available. Debian, for example, didn’t have the patched packages ready until after 9 pm.
Our day at a glance:
- Midday to the afternoon: We assessed the situation and made preparations. As a precaution, we isolated our own systems running PHP outside of Beach behind a firewall.
- 4.00 pm: The PHP team released the patched versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A few minutes later, our builds started.
- From 7.00 pm: The new images are ready, and we redeploy all Beach instances. After around six minutes, the vast majority of projects are running on patched PHP.
- In the evening: We check all cluster containers one by one and update a handful of stragglers individually. We then emailed all active Beach customers to inform them.
Why we didn’t take everything offline
Some of you asked us this question in the days that followed, and it’s a valid one. The BSI and the US CISA had recommended taking websites offline, and some hosting providers did just that, in some cases for several hours. With traditional shared hosting, this is an understandable decision: there are often a great many websites running on the same server, with shared file systems and a diverse mix of PHP applications. A single exploited vulnerability can have far-reaching consequences in such an environment.
Beach’s architecture is different, which is why we reached a different conclusion.
Applying the patches was quicker than shutting down and restarting
The recommendation to take websites offline applied specifically to cases where no updates were available. In our case, there was a gap of around three hours between the release of the patches and their roll-out to almost all instances (and yes, that time really did seem to drag on forever). Most hosting providers and companies, if they took any action at all, only took their systems offline when the patches were released at 4 pm. So we would hardly have gained any time; it was a very narrow window.
Each Beach instance runs in isolation
With Beach, each instance runs in its own container, and each project has its own isolated area within the cluster. Network rules ensure that an instance can only be accessed by the upstream web server and by our operations and monitoring systems, not by other projects. PHP runs there without administrator rights and without the ability to obtain such rights. The containers have no access to the cluster’s control systems.
Even if an attacker had been able to execute code within an instance, they would have remained confined to that single container.
Every Deployment ensures a clean state
The file system of a Beach instance is ephemeral. The application code is loaded fresh from the built image at every start-up; everything else is deleted upon the next restart. A typical consequence of such security vulnerabilities is a planted file – for example, a web shell – which an attacker can later use to gain access again. With Beach, such a file does not survive a container restart.
With the rollout on the evening of 21 October, we replaced every single container. Even if something had been injected previously, it would have been wiped out as a result.
Downtime is always damaging
For an online shop, a members’ portal or a company website, an outage lasting several hours causes real damage. We therefore weighed up the options: a short-term risk in isolated, temporary containers on the one hand, versus a guaranteed outage for everyone on the other. The decision wasn’t an easy one for us either, but we’ve decided to stay online.
However, we also believe that the decision to take a website offline lies with the respective operator. Some of you had specific security requirements and replaced your website yourselves with a static page or placed it behind password protection. We were happy to help with this. With Beach, this can be done in a matter of minutes.
Incidentally, where the balance of considerations was different, we did indeed take sites offline: we immediately isolated internal systems that aren’t built like Beach and only made them available again after the update.
We have been monitoring this closely
To exploit such a vulnerability, an attacker usually needs to send thousands of requests to the same target. We analysed the metrics for all Beach clusters for 21 October and compared them with the previous day: requests per website, error rates, crashes and memory issues with PHP processes. We found no evidence of a successful exploit.
Even if something were to have slipped through our net, given the isolation and the complete replacement of all containers that evening, we see no way in which an attacker could have established a permanent foothold.
What we learn from this
There’s always something to learn and improve – that’s precisely what we strive for. Even though the day ended on a positive note for us, there are a few points we’ll be addressing afterwards:
- Faster builds: Building our PHP images took around two and a half hours. That was the biggest time drain. In future, we’ll build the images on our own infrastructure and separate PHP from the extensions, so that when a security update is released, only PHP itself needs to be rebuilt.
- Protection before patches are available: Until a patch is available, we want to be able to apply protective measures – such as adjusted PHP settings or filter rules – centrally to all instances simultaneously.
- Earlier notification: Many of you contacted us individually on 21 October to ask whether we were aware of the issue. Next time, we’ll get in touch proactively as soon as a critical vulnerability is known and keep you up to date. We were perhaps a little too preoccupied with our own affairs at the time…
What you should do
You don’t need to do anything on Beach. Your instances have been running on the patched versions since the evening of 21 October.
If you also use PHP outside of Beach, for example locally, in your own CI pipelines, on other servers or in Docker images, please check that an up-to-date version is running there. We have also updated our public images on Docker Hub.
And if you’re still using an older version of PHP or aren’t sure how to update your project to the latest version: get in touch with us – we’ll be happy to help.
PHP is still our favorite ecosystem
We think that many media outlets reported on this security vulnerability relatively well and accurately. Sometimes, of course, the wording was a bit quirky. And every now and then, one could get the impression that “PHP is a problem” or that it had always been clear that PHP isn’t very secure. That’s obviously not the case—you can develop and run wonderfully clean and secure applications in PHP (but, of course, also very messy and insecure ones).
But what’s clear is this: PHP forms the backbone of the modern internet; an incredible number of companies and organizations depend on PHP continuing to be developed and maintained. And yet, it’s a small team—mainly made up of small companies and freelancers—that keeps everything running.
That’s why we’d like to say thank you: to Volker Dusch, Nils Adermann, Tideways, the entire PHP team, and the PHP Foundation. Behind every release like this lies months of often unseen work, coordination with researchers, distributions, and hosting providers worldwide, and ultimately an early release under enormous pressure.
