Keep Calm and Apply Your Fixes
Surrounded by wars, climate concerns, fuel prices and inflation, peaceful protests that turn into riots, natural disasters, reports about mysterious viruses, the world suddenly exploded because of one short message on the PHP project’s announcement mailing list on 20 October:
“We want to inform you of an upcoming PHP security release that addresses
two critical vulnerabilities”
For the majority of the devops engineers this sounded like just another day in the office - new release, timely update. Some of them were even still more concerned about how the Google Cloud outage in its London region earlier this week, caused by a power event, disrupted the operations of a number of organisations across Europe. Yet somehow this particular short message turned into the biggest problem of the globe and a reason for recommending to entire web platforms and businesses to voluntarily shut down until updated accordingly. While we do not want to underestimate the potential harm that can be done if such critical vulnerabilities are actually exploited, we prefer to give you a more relaxed and mindful point of view.
Let’s start with the vulnerabilities themselves. Very simply put, someone reported a mechanism with which a malicious hacker can run their own code on a web server without logging in (you will see the term “unauthenticated remote code execution”), just because the server uses PHP to handle web requests.
Objectively speaking, PHP sits behind a very large share of the world’s websites. PHP remains one of the most popular programming languages for web services, and is the language in which some of the top 10 content-management systems in the world are implemented. We are sure that in the last few days the number of searches about “is software A written in PHP?” has increased exponentially.
But also, objectively speaking, other software can be just as common - e.g. database systems, email servers, and the operating systems themselves! If you open the Linux Kernel Vulnerabilities Tracker, you will see a mindblowing list, with hundreds of entries just for this September. And if you dig deeper, you will see that every piece of system software has trackers and provides security releases, with an urgency corresponding to the criticality. But most of the time you don’t read about it in the local newspaper, do you?
The next thing that comes to mind is, of course, once the critical vulnerability is discovered, how can the malicious hacker actually get in? We have been overwhelmed by movies and series where the main protagonist, or antagonist, opens their laptop, presses a few keys on the keyboard and says “I’m in!”. All in a matter of seconds, or, if the movie is more suspenseful, minutes.
There is a partial truth to this - if the hacker has already identified a server that runs the vulnerable software, if they have prepared the program or tools that take advantage of the vulnerability, then yes, they will press “Enter” and gain the access. But this is like ski jumping in the Olympic games - where you actually train for four years (or more), make a lot of attempts, adjust your technique, adjust your equipment, and then you get to do this one big jump. And 10 seconds later it’s all over.
Preparing a hacker attack is a serious undertaking and it needs time, it needs trial-and-error, it needs computational power. Also, it needs good knowledge of the vulnerability - the best would be to actually discover it yourself. Once the project’s security team knows, the race to a fix begins, although fixes are not always quick: in this case the underlying memory problem was first spotted in 2024 and the full fix only shipped this week.
For the record, this is why PHP’s original notification did not contain any specification of the vulnerability, and this is why they reserved the right to release the fix earlier than announced, potentially prematurely, should information start leaking. And that is exactly what happened: when the CVE numbers began circulating online on 20 October, PHP published its notice that evening and brought the release forward from 22 to 21 October.
We should be honest, though, that this time the head start was short. On the evening of 20 October one of the research firms involved mistakenly published a video of its working exploit, and copies spread quickly. On the morning of 21 October a software distributor published patched builds more than six hours before the official release, which let anyone compare the old and new code. Cloudflare reported early attacks before the fix was even out, and by the afternoon security researchers were seeing active exploitation attempts against both vulnerabilities. The ski jump took hours, not years. That is not a reason to panic, but it is exactly why the patch window matters.
One topic that cannot be skipped is, of course, AI and its role in all of this. There has been so much talk about how AI possesses the power to even extinguish humanity, that once it became known that AI tools were involved in finding the PHP vulnerabilities and, therefore, the exploiting code can be constructed with the help of AI, significantly reducing the time needed for development and therefore the time needed for reaction - naturally people started panicking.
The truth is, however, that this tendency has started way earlier and various softwares have managed to and keep identifying critical vulnerabilities via AI analysis. The computational power that AI harnesses makes it an extremely useful tool for prevention - discovering deeply hidden flaws, complex scenarios that may end up in a disaster, analysing network traffic and applying adequate measures during DDOS attacks, etc.
Simply put, any software that announced a security release because of vulnerabilities (whether critical or lower grade) within the last 12 months most probably diagnosed them with the help of AI and quite possibly used AI to validate the reports, while people still decided on and wrote the fix. This is the current standard in IT development and nothing to be scared of. PHP was just another example, but with the popularity of the language, it made it to global news, while most others before it did not.
Finally, let us speak a little bit about the recovery in case of such critical vulnerabilities. All software companies around the world gathered for urgent meetings and discussions - are we using PHP, what should we tell our customers, do we need to do anything? Yet, like we said, hundreds of potential dangers in Linux in September did not cause such an erratic reaction.
Overall, most people on fully managed hosting do not need to do anything themselves. We live in the era of software and infrastructure as a service. We pay hosting companies and cloud providers, which take care of everything for us and we’re just providing the code or the built version of our web site or system. We don’t install the operating system on the server, we don’t install the database system, we don’t install PHP, or Java, or .NET - this is the responsibility of the provider.
Automatically, this means that regular updates and applying security fixes is also the responsibility of the provider. The exception is anyone who runs part of the stack themselves. If you manage your own virtual machines, ship container images that bundle PHP, or still run PHP 8.1 or older (the PHP project only patches 8.2 and newer), the update is your job, not the provider’s. Under the shared responsibility model most cloud platforms use, the provider patches what it runs and you patch what you run. So the first calm question is a simple one: which layer is ours?
Responsible providers follow the news sections of all major system softwares, so they read the announcement on 20 October about this upcoming security release, they were prepared on 21 October 14:00 UTC and they started updating all of their servers. As they usually do. And not because it was PHP specifically. Their daily routine, among other things, includes being constantly prepared for alerts and applying fixes urgently. Reputable providers also tend to apply all new releases - no matter whether security or bugfix - as quickly as possible, to limit the impact of any malfunctions over their customers.
Naturally, customers have the right to ask for a report over a specific situation. And you should do so! Viral situations like this one may help you assess your relationship with your service and software providers and should generally acknowledge that you made the right choice by trusting them.
Just don’t panic. Even if your web system was on the list of potential victims, the expectation is that it is no longer running any version of any software recognized as vulnerable. And the expectation is that the update was applied within hours of release, leaving only a short window for anyone to harm you. It is still worth asking your provider to confirm when they patched, and whether they saw anything unusual in their logs on 20 and 21 October. So that you can eventually breathe a sigh of relief and mindfully realise that, yes, something very bad could have happened.. but it did not! Because people did their job.
What this means for Vector Labs?
At Vector Labs we build and run AI systems for organisations in healthcare, financial services, manufacturing and media, where a security incident is a regulatory matter as much as a technical one. Weeks like this are a useful test of whether our processes, and our clients’, hold up under pressure.
The bigger lesson is about AI. The same tools that helped find these flaws also shorten the time between a fix being published and an exploit appearing, because comparing old and new code is exactly the kind of task AI now does well. That shifts the advantage to organisations that know precisely what they run and can patch it the same day. In practice this comes down to three things: an up-to-date inventory of the software components in every system, clear ownership of each layer between the client, the cloud provider and us, and automated build and deployment pipelines, so that a security update is a routine release rather than an emergency.
So keep calm, but also keep a list. If you are not sure which layers of your systems you own, or how quickly you could ship a security update, that is a conversation worth having before the next announcement, and one we are happy to have with you.
