PHP2Shell: why the fix was the easy part

Every website running PHP was handed the same fix on Wednesday. How quickly each one could actually apply it is where things got interesting, and we think that deserves more attention than the vulnerability itself.

The headline facts are well covered by now. Both flaws are rated 9.2 for severity and allow an attacker to run code on the server, and CERT-EU has urged organisations to patch immediately. Fixed releases are out for PHP 8.2 to 8.5. Cloudflare and watchTowr reported exploit attempts on the day of release, although no successful attack had been confirmed at the time of writing.

Across the sites we look after, the split was clear. Sites that have had regular updates took the patched version within 24 hours. Others, some of which haven't been updated for four or five years, can't take it at all without an upgrade. Both groups are protected for now, but they're on very different paths from here.

We didn't wait for the patch

Bringing the release forward a day after the leak left every team with less time than planned, and patched packages reached some operating systems well before others. Rather than wait, we applied configuration changes across our sites as soon as the issue surfaced, closing off the known routes to exploit the flaws. Our dev team quickly took care of the rollout, so every site we manage was covered the same day.

There was a trade-off. On some sites, the changes temporarily switch off file uploads, which is why you may not be able to add images or documents right now. Security comes first while the permanent fixes go in. Our own website is in the same position right now.

Up-to-date sites barely noticed

For the sites we've built or updated recently, the fix was close to a non-event. They run on a supported version of PHP and are hosted with Servd, whose team applied the mitigations and the patch for us. All that's left is a round of deployments and testing.

Modern code, a capable hosting partner and regular updates did the heavy lifting there. Clients on a retainer or our enhanced hosting won't see a bill for any of this, because keeping their sites current is already part of the deal.

Don’t already work with us on retainer? Get in touch to find out more about the packages we offer. 

Older sites need more than a patch

PHP 7.4 reached end of life in November 2022, and full fixes for PHP2Shell have only shipped for supported versions of PHP 8. PHP's security team has published limited backports for a few older branches, but they're aimed at teams who compile PHP themselves and won't help most hosted websites. W3Techs data shows more than a quarter of PHP websites still run version 7, which puts a lot of the web in the same position.

These sites still work, which is usually why they've been left alone. Getting them onto a patched version can mean updating the CMS, plugins and custom code, testing everything and, in some cases, moving servers.

In the meantime, our mitigations keep these sites protected. CERT-EU is clear that measures like these are a stopgap, though, so full security still means upgrading.

What to do now

Whoever looks after your website, these are the steps we'd take this week.

1. Check your PHP version. Your developer or host can confirm it in minutes. Anything older than 8.2 is outside PHP's official security support, and 8.2 itself drops out of support at the end of this year.
2. Confirm your site is patched or protected. You should get a clear answer on whether the fixed version is installed or temporary mitigations are in place.
3. Ask what the mitigations affect. Some, including ours, switch off features such as file uploads, so it helps to know what your team can and can't do in the meantime.
4. Get an upgrade scoped if you need one. A site that can't run a supported version of PHP has no permanent fix without it, and booking early helps because plenty of developers will be busy with the same work.
5. Watch for anything unusual. Unexpected files, unfamiliar admin accounts or sudden changes in performance are all worth flagging to your developer straight away.
6. Agree how your site will be looked after from here. Even one upgrade a year turns the next emergency into routine work.

If we look after your site

There's nothing you need to do in a hurry. Every site built on PHP that we manage is protected, and where an upgrade is needed, we'll be in touch with a clear scope and cost. If you'd rather not wait, let us know, and we'll get your upgrade booked in.

We're sticking with PHP

Some people will use this week to call time on PHP, or on WordPress. We won't be joining them. PHP still runs nearly 70% of websites with a known server-side language, and the alternatives aren't immune. Node.js, which sits behind plenty of headless builds, issues security releases for critical flaws of its own.

What this week exposed is the difference between sites that get looked after and sites that don't. Regular updates turned an emergency patch into a morning's work, and they keep a site within easy reach of the next fix.

Want to keep your site on the right side of that line? Get in touch to find out more about our website support and hosting.