Dealing with the recent PHP vulnerabilities
The ability to patch a large number of sites at speed does not come for free. It’s the result of many years of careful work from both Platform Engineers and Developers working together.
You may already have heard that two critical vulnerabilities in PHP, a piece of software that powers 70% of the web, were discovered recently and fixes for these were released last week. It’s not often that technical events are covered by both BBC News and The House of Lords which gives you an idea of the scale of the response from site owners and suppliers.
How dxw responded
News of the vulnerabilities was announced by the PHP Foundation on the evening of Tuesday 20th, with patches scheduled to be released at 3pm the next day. This kind of responsible disclosure enables IT teams to prepare for a rapid response, without disclosing details of the bugs that might help an attacker, and was widely shared on social media.
At dxw we keep a close eye on threat intelligence, so one of our Platform Engineers raised the upcoming bug fixes with the out of hours team to say that we were aware of them and would declare an incident in working hours the next day.
The PHP Foundation had suggested a small number of mitigations that could be applied to sites to keep them safe before the patchers were released, and so we made sure those were applied to our systems.
Our in-house PaaS and custom tooling has been built specifically to allow for the fast application of patches like this. We have a team available to handle this sort of incident but, if necessary, large scale updates can be done by a single Developer or Engineer.
We use packages from an AWS mirror, rather than the operating system vendor directly, partly for speed and also to avoid rate limiting when we have a large volume of deployments. Once the patch became available in the AWS mirror we use, we applied it across all sites we host which run on PHP, prioritising high profile sites more likely to be subject to targeted attacks.
Some clients had already been in touch to ask for updates, and once the patches were out, we started contacting the rest. Some clients wanted detailed information about how the sites were behaving and what we were seeing in the logs. We saw a reasonable amount of scanning for vulnerabilities, but in the end it was more than a day before we saw clearly identifiable scans for the vulnerabilities .
What you might have missed in the noise
A number of website owners took their sites down during the upgrade, including several government websites. News coverage of these events was quite vague, so it may have looked as if a lot of sites had been hacked. In fact, all or almost all of these sites would have been offline while they were waiting to be patched.
Delays like this can happen for a number of reasons. Very small IT teams might be unable to move quickly if some staff are on leave, for example, but for larger teams the most likely reason for a slow patching process is that the site is not running the latest version of PHP (version 8). Updates like this can vary in their complexity: from quite straightforward, taking a few hours, to multiple days of work upgrading a large number of dependencies, and in some cases replacing them altogether.
Patching at speed and scale
The ability to patch a large number of sites at speed does not come for free. It’s the result of many years of careful work from both Platform Engineers and Developers working together. dxw has been hosting government and other websites since 2012 and, in that time, our in-house PaaS has gone through several iterations, each of which has made it easier and quicker to respond to incidents.
In 2022 we started building custom tooling to manage sites at scale, which has been instrumental in our ability to make changes quickly.
We have maintenance contracts for all of our clients, which enables us to take time out for incident response, but more importantly to keep sites up to date with critical dependencies like PHP.
The last version of PHP version 7 reached the end of its support period in 2022. Operating system vendors were offering security patches up until April 2025, but any sites still running PHP 8.1 or lower last week would have found it more difficult to update. Over 70% of websites run PHP, and currently 35% of those are still on an unsupported version of the software.
Sites running an unsupported version of PHP have two options:
- take the site down for an extended period of time, update, test, and then put the site back up, or
- wait for a period of time in the hope that a volunteer such as Ondřej Surý will “backport” the patches for PHP 8 to their older versions of PHP.
At dxw we use versions of PHP, and other critical software that are provided by operating system vendors. This means we receive security updates for all software packages we use for the full lifetime of the operating system we build on. This also means that we stick to one version of PHP for a period of time, so developers are not writing code against a moving target. When we do upgrade the operating system, we upgrade every piece of software in concert, so we can be sure that all the software we need will work together, putting us at less risk of an update introducing bugs.
Why price points really matter for cybersecurity
Running a website is an expensive business, but there are ways to cut the costs. For buyers the main cost saving is to use a supplier who does not run their own hosting infrastructure but uses a third party supplier for hosting. This is cheaper, and commodity hosting like this is often very reputable, but what you lose is the ability to control the response to a cybersecurity incident.
A supplier like dxw with their own hosting platform can answer detailed questions to any CISO about the configuration of the infrastructure and the behaviour of visitors and attackers. They should be able to apply mitigations and patches quickly and communicate clearly about what has been done. A supplier using a third party hosting platform would need to raise a ticket for that platform and, in most cases, will have a limited ability to control the configuration of the software and the platform protections around it.
Nobody likes paying more money, but the advantage you get with a more comprehensive service is the continual improvements and updates that allow an incident like this to be handled swiftly.
More like this…
In the same week that these PHP vulnerabilities were made public, the government launched the Be Ready campaign (a website hosted by us) which aims to prepare citizens for utility outages which might be caused by weather events or a cybersecurity incident.
With AI systems discovering more and more vulnerabilities in old software, it seems likely that patching like this will need to be done repeatedly, at least for the next few months. Buyers and suppliers who have invested in their platforms may find this disruptive, but it should be straightforward.
Although our incident team from last week has been disbanded, the continuous work of improving our systems continues.