Our 24 hours with PHP2Shell

At 2pm on Wednesday 21 October we were sat watching for an emergency update to the software that runs most of the internet. By Thursday morning we had patched the servers, checked 30 client websites one by one, worked out that most of the alarming looking stuff was completely fine and drunk a volume of coffee that no doctor would sign off on. This is what we did and why none of our hosted clients had to do anything.

What PHP2Shell actually was

PHP is the software underneath roughly 70 percent of all websites. WordPress, Statamic, Laravel, Magento, Drupal, Joomla, almost everything the average small business runs on is PHP underneath. On Wednesday the PHP team shipped an emergency fix for two bugs rated 9.2 out of 10, nicknamed PHP2Shell. A specially crafted request to a vulnerable server could let an attacker run commands on it with no password, no login and almost nothing in the logs to show it had happened. The bug had been quietly sat inside PHP for seven years.

That is as much of the explainer as you are getting from me, because every security blog on the planet is writing the same one this week. If you want the proper technical write-ups, CrowdStrike and Datadog Security Labs both have solid ones. The rest of this post is about what happened at our end, because that is the part only we can tell you.

Where we were at 2pm on Wednesday

We had the heads up before the fix was public. The PHP team brought the release forward by a day because details had started to leak and attackers were already probing for it, so from Wednesday lunchtime we were sat watching for the patched versions to drop. When they did we moved pretty quickly.

In order: updated PHP on every hosting server we run to the patched versions. Updated Plesk, which is the control panel software and ships with its own copy of PHP for the server management side. Restarted every PHP service, because this is the bit that catches people out. If you update the files but do not restart the service, the old vulnerable PHP is still the one answering requests. Then checked the servers for any old unsupported PHP version sitting on them from a previous life, because an unpatched version lurking in a corner is just as useful to an attacker as the one on your main site.

The Laravel Forge servers that run our Statamic client sites got the same treatment in the same window.

Server side done. Then the actual job: 30 client websites, each one checked by hand.

The nervy emails

That was the point the first few client emails started coming in. People had seen the news. Fair enough. I was elbow deep in checks and would rather have sent one proper update once everything was actually done, but telling a client to sit tight while you work is also part of the job. So I replied to each one calmly, said we were on it, said I would come back with the full picture when it was in front of me and carried on.

What normal looks like, and why it matters

When you ask a server to list every file that has changed in the last 48 hours, you get back a list that looks terrible if you have never seen one before. On every site we checked there were things on that list that would have made less familiar eyes panic.

Hundreds of files from one SEO plugin had changed on one site. For about ten seconds this was alarming. Then it became obvious the plugin had quietly updated itself the night before. Not a hack, just a Tuesday.

The firewall files that belong to Wordfence always show up as recently changed, because Wordfence constantly rewrites them. If you squint at the list, the security plugin looks like the main suspect. It is not an unusual thing to spend half an hour investigating the thing that is supposed to be investigating the attack.

Every uploads folder on every WordPress site contains tiny index.php files that do absolutely nothing. They are harmless placeholders that plugins drop in to stop people browsing the folder directly in a browser. Technically a .php file in uploads is a red flag. In practice it is a plugin being tidy. Knowing which is which is the entire point.

Alongside that we ran WordPress core and plugins through the official checksums published by WordPress.org. The command compares every file on your site against the version it is supposed to be, and spits out a very satisfying Success line when the fingerprints match exactly. That is a very nice line to see 30 times in a row.

We also went through the admin user accounts on every hosted site, looking for any login that should not have been there. All clear.

The reason I am going into any of this is that none of it is work a script, a chatbot or a boilerplate security scanner would reliably get right. Spot the recently changed SEO plugin, work out if it is a hack or a Tuesday, move on. That is what you are paying someone who already knows your site for.

If this all sounds like the kind of thing you would quietly like someone else to be doing on your behalf, we wrote about what ongoing support actually covers earlier in the year, and the general argument has not aged a day.

The AI bit (because I am contractually obliged to mention it)

The PHP2Shell bug was found with the help of AI. Researchers at Wiz, OpenAI's Codex Security team and Calif used it to go through PHP's internals looking for memory safety flaws, and it turned up something that had been quietly sitting there for seven years.

I am on record as being a bit of an AI snob about the fun bits. I do not want it near your logo, your brand design or the pieces of a website that are supposed to carry a bit of human in them. I am keeping that position. What I will cheerfully give it is the boring jobs. Reading seven years of PHP internals looking for a dormant memory bug nobody else noticed is one of the most boring jobs on earth. Making your logo is not.

Why we waited to email everyone

The email to our hosting clients went out on Thursday morning. One email, after everything had been checked and confirmed, explaining in plain English what had happened, what we had done and that there was nothing they needed to do.

That is a deliberate choice. The temptation when a story like this is doing the rounds is to fire off a quick "we are all over it, nothing to worry about" the same afternoon, because it looks responsive. The problem is you then have to send a follow up at 6pm because you found something you had missed, and now the client has two emails from you where one of them contradicts the other. Better to go quiet for the few hours it takes to actually finish, and send one thing that is true.

For the record, I got through roughly 40 cups of coffee between the first update at 2pm Wednesday and that email going out on Thursday morning. I would recommend 40 cups of coffee as a working strategy about as strongly as I would recommend doing your own hosting.

Why pay for hosting when there are three pound deals out there

This is the question we get asked more than any other. Why pay us for hosting when you can get it for about three quid a month somewhere else.

The honest answer is that you can, and if you are the sort of business owner who enjoys watching security news, keeping your own server patched and running a check across your site every time something like Wednesday happens, those cheap deals are completely fine. No sarcasm. If that is you, go for it.

Most business owners do not want to do any of that. They want someone who already knows how their website is built to pick up a job like this one, with no ticket queue, no chatbot asking them to describe the issue in three to five words and no gentle suggestion to clear their browser cache.

Before I did any of this I spent years as a plant mechanic, which is a long winded way of saying I used to fix diggers. A well serviced machine on a building site is invisible. Nobody ever thanked me for the digger that did not break down. They did however find me very quickly on the morning one did. Hosting is exactly the same job. Done properly, you should barely know we are here.

We are not the cheapest option out there. When clients move to us from another agency, though, they almost always find we are a bit cheaper than what they were already paying, and they get a lot more for it.

If you are not sure whether your current host has patched for PHP2Shell, or if you would rather not find out the hard way next time something like this comes around, send us your URL. No form, no obligation. If everything is fine, we will tell you that.

One last thing

The servers are patched. The sites are clean. The coffee machine has filed a formal complaint.

From now on, the only Two Shell I want to be worrying about is this one.