The PHP vulnerability of 21 October: what we did and why

What was going on

On Wednesday morning the PHP project announced two critical vulnerabilities, quickly dubbed “PHP2Shell”, both with a score of 9.2 out of 10. Through these vulnerabilities, an outsider could run their own code on a server running PHP, without logging in. That gives access to accounts, passwords and protected parts of a website, and in the worst case to the server itself.

What made it extra tense: the information about the vulnerabilities had already leaked a day earlier and was circulating on social media. The fix was scheduled for later in the week and was brought forward to Wednesday at 16.00. Until then, every server with PHP that is reachable from the internet was probably vulnerable, and malicious actors knew that too.

Many large organisations therefore made the same choice as we did and took their websites offline as a precaution, including the Dutch House of Representatives, the NCSC, DigiD and MijnOverheid. The NU.nl live blog gives a good picture of that afternoon.

What we did

We did not wait for something to go wrong. This is how the day went on our servers:

• 13.30PHP switched off on all our servers. Websites running on PHP showed visitors a short explanation.
• In the meantimeEmail on your domain was sent and received as normal. Your website and data remained intact: nothing was deleted or changed.
• 16.00The updated PHP versions were running and the websites were reachable again.
• AfterwardsChecked the servers for traces of misuse. No signs of an intrusion were found in our logs.

The reason we already had the updated versions running at 16.00 is that we monitored the update continuously from the afternoon onwards and installed it the moment it appeared.

Apologies for the inconvenience

A website that cannot be reached for two and a half hours is a nuisance, especially if your customers were looking for you that very afternoon. Some of you found the website already offline before our message came in. Given the seriousness of the vulnerability, we chose to secure the servers first and only then send an email. Our apologies for the inconvenience.

At the same time, this step fits with the way your hosting is managed by us: we actively keep an eye on the servers ourselves, and if necessary we step in quickly. Better an explanation page for one afternoon than a site that later turns out to have been taken over.

Why this will happen more often

The vulnerable code had been in PHP for more than ten years and has now been found with the help of AI. That tooling is available to malicious actors too. We therefore expect vulnerabilities to follow one another at an ever faster pace. Websites with a CMS such as WordPress or Joomla need extra attention: they rely on PHP as well as on plug-ins and extensions from dozens of different makers, and any of those components could contain the next vulnerability.

That is why we are increasingly converting existing websites into static websites, without PHP, WordPress or Joomla. This eliminates many potential vulnerabilities, and when the next PHP vulnerability comes along, such a site simply stays online. Only a contact form then still uses a small PHP script, unless another solution is available. You can read how that works at having a website built without PHP.

Would you like to know whether this is a suitable solution for your website, or do you have questions about Wednesday? Send an email to info@innodigi.nl or get in touch.