In an unusual turn of events, PHP - the 'thing' that sits behind about 70% of the world's websites - hit the headlines this week.
In this post we look, in layman's terms, at what it is, what it does, what the problem was, and how we mitigated against it for our hosting clients.
What is PHP
Dating back to about 1993, originally called Personal Home Page, it's a scripting language. The thing that serves your website processes the PHP code, and that code can be part of - or the entirety of - the website that's presented back to you.
So, for a simplified example, on a website selling widgets, you don't create one page for every type of widget you sell - that would be unmanageable. You create one single page template, and when a visitor wants to view details of a specific widget, the PHP gets the information about that widget - name, price, description, picture, etc. - from somewhere (most probably a database) and then inserts the information into the relevant points in the template, and the web server sends the completed page back to your browser.
In practice, PHP handles a lot more behind the scenes. And often, people don't know it's there, they only know the software that they directly interact with to manage their site. So Wordpress / WooCommerce? They run on PHP. Magento? Ditto. Laravel, Joomla, Wikipedia...all these things run on PHP behind the scenes. Hence its prevalence.
Why the urgency
On Tuesday evening, UK time, the team who maintain PHP warned that an emergency fix was coming - AI analysis of the codebase had discovered a couple of serious holes, and those holes needed to be plugged. If not, they could allow someone to send a carefully crafted 'request' to your website that would allow them to run their own code on your server and, in effect, take it over.
PHP is released in scheduled versions, and this flaw was present in versions going back to PHP5.4 (released back in 2012) - we're now on PHP8.5, with PHP8.6 coming next month.
Officially, though, only certain versions are still supported, so official patches were going to be released only for v.8.2, 8.3, 8.4 and 8.5. There was therefore a lot of talk of "if you're running on a version older than 8.2, the sky is falling in - not true, as we'll see later.
What this meant in practice
When released, the patches would, themselves, reveal what the underlying issues were. This created a race, in effect - once the patches were released, good people would have to patch PHP before bad people could work out the exploit and did bad things to exploit it.
There were indications of what the issue might be, though - partly because of when the flaw first cropped up (figure out what was changed when PHP5.4 was released and you're halfway to figuring out where the vulnerability lies, but not necessary how to exploit it) and partly because one 'security' company released a video of the exploit before the patches were released. Not ideal.
So a few steps could be taken before the patches were released - modifying the server's PHP settings and blocking certain types of request. The latter bit, in particular, could stop a few bits of some websites working properly, but in the main, most could carry on in the meantime with these restrictions in place.
Magento 2 was the exception - blocking the certain types of request meant that the cart, login, and other bits and pieces stopped working. So those sites had to be put under maintenance - there's little point leaving a shop up if people cannot actually shop - until the patches were rolled out.
When the patches went live
Nothing happened - most sites, at least. Most self-maintained servers, such as ours, don't get the PHP versions directly from PHP, they use 'downstream' providers. So whilst the patches went live, there was a wait of a couple of hours whilst the downstream provider integrated it into the packages that they provide.
Those packages went live at about 6PM UK time. But so many servers (we're talking in the millions) wanted to get the packages installed ASAP that it was as though ten million people were queueing for a concert that could fit them all in, but they were all trying to get through one solitary door.
So we took the executive decision to leave the stopgaps in place until the morning. 6:00 AM UK time, and the queue had died down. PHP could be updated, the temporary blocks released, and all was pretty much well with the world. Magento stores with certain third party modules wouldn't let admins login because those modules tried to talk (legitimately) to an external server which wasn't responding. But other than that.
Why the sky didn't fall in for older sites
We said, earlier, that PHP themselves were only going to release patches for versions 8.2 to 8.5. Older versions weren't up the creek, however - generally speaking it's quite easy to take what's been done to patch a later version and apply it to the earlier version. So the PHP official patches didn't cover older versions, but the downstream providers did. We still have one or two sites running on PHP7.4 (for long and complicated reasons) and they were patched without issue.
Lessons learned
The vulnerability was discovered by AI. It wasn't a failure on the part of people who originally wrote the code, it was just an issue that no-one could have been expected to think of.
This is only going to happen more frequently - and not just to PHP, but to lots of other scripting languages and server software.
More people know about PHP today than at any point in the previous 30 years. Even if they don't really know what it is.