PHP2Shell: How We Handled the Critical PHP Vulnerability

On the 21st of October, PHP, the software behind a huge share of the world's websites, released fixes for two critical security flaws. Details had leaked early and attacks were expected within hours. Here is how we kept the websites we host safe that day, and what it means for your business.

A warning that couldn't wait

PHP is the programming language that quietly runs a large part of the web, from WordPress sites to bespoke business systems. On the 20th of October, the PHP team announced that fixes for two critical flaws would be released the following afternoon. It soon emerged that both could let an attacker take control of a web server without ever logging in. The pair soon became known as PHP2Shell.

By the next morning, details of the flaws were already circulating. The UK's National Cyber Security Centre told organisations to update straight away and, where that wasn't possible, to "consider taking the system offline until it can be fully mitigated".

Planning before the fix arrived

The first alert went round our team just after 6am, hours before the fix was released, and by mid-morning everyone was working on it. Before anything changed, we:

• listed every server we host that runs PHP, including the less obvious ones, such as staging sites and background systems

• checked exactly which version of PHP each one ran, and where its updates come from

• took snapshots before making changes, so any change could be rolled back in minutes

• prepared a maintenance page that could go up in seconds and, where we manage it, made sure each server could only be reached through our security and content delivery network, so nobody could go around it

Every server had its own card on our project board, so the whole team could see where each website stood at any moment.

Telling our clients first

Most of our clients heard from us that morning, before the National Cyber Security Centre had published its guidance. The email explained what was happening, what we were doing about it, and that there was nothing they needed to do.

Some of our clients' websites are hosted elsewhere. Where a host was slow to confirm, we told the client exactly what to ask for, including the precise version number to look for. "We're on a supported version" and "we've installed the fix" sound alike, but they are not the same thing.

Patching, and protecting what couldn't be patched yet

The fixes were published in the afternoon, and we applied them in order of risk, starting with the most exposed servers.

Not every server could be updated straight away. Some older servers run operating systems that no longer receive ready-made updates, so no fix was coming for them at all. Rather than leave those websites exposed overnight, we:

• built the fixed version of PHP ourselves for three of them, tested it and had those websites back online the same evening

• upgraded the operating system on others, so they could take the standard update

• kept the rest behind the maintenance page, or applied PHP's recommended interim protections and locked them down

By the end of the day, every server we host had been updated, protected or taken offline.

Checking that nothing got in

Patching closes the door, but it doesn't tell you whether anyone slipped through first. So we wrote a check that looks for the traces these flaws would leave behind: suspicious requests in the web logs, unexpected changes to website files, new user accounts or scheduled tasks, and hidden back doors. We have run it on every client server we host, and it found nothing.

What this means for your business

Most business owners never see this kind of work, and that is how it should be. Still, it is worth knowing the answers to a few questions:

• Does someone know every place your business runs PHP, or any other software that might need an urgent fix?

• Can your provider update your servers the same day, and roll back quickly if something breaks?

• Is there a plan for older systems that no longer get updates?

If any of those is a "not sure", a server checkup is a good place to start. For some businesses, this week has also been a nudge to move older servers onto a supported platform, so the next fix takes minutes rather than a day. If your website runs on WordPress, our guide to the security risks hiding in your WordPress website covers the other side of the picture.

Keeping your website safe is what we do

At iSOS, we specialise in hosting, security and day-to-day care for business websites and systems, with round-the-clock server monitoring behind it. If you'd like to know how your website would have fared on the 21st of October, or you want someone to look after it for you, get in touch and we'll be happy to help.