PHP2Shell: what happened, and why keeping your website up to date is essential
Part 4 of 5 in our October series: small, free steps to take control of your own cyber security.
On Wednesday afternoon, as you may have seen in the news, the team behind PHP released an emergency security update.
You may never have heard of PHP – until this week, many people hadn’t. But there’s a strong likelihood that your website relies on it. PHP is the programming language that a large proportion of websites run on – including WordPress, Magento, Drupal and Joomla sites, as well as many custom-built sites like the ones we make.
The two flaws it fixed – now known as PHP2Shell – are among the most serious ever found in PHP. So what actually happened, what did it mean for our clients, and what can we take away from it?
What was the problem?
Simply put, the flaws could have let an attacker run their own instructions on a website’s server, without needing a username or password. Both were rated 9.2 out of 10 for severity.
These flaws were in PHP itself – not in a plugin or add-on – and affected every version of PHP released in the last decade, right back to PHP 5.4.
What was at stake?
If an attacker can run their own instructions on your server, they could take control of your website. In practice, that could mean:
- Copying customer details, orders or any other data stored in your systems
- Surreptitiously adding code to your checkout to capture card details as customers enter them
- Changing your website, or even using it to pose as you, send spam or attack other sites
- Taking your website offline
Commonly, a business doesn’t realise its site has been compromised until it affects its customers.
How are flaws like this found and fixed?
Most serious vulnerabilities are found by specialist security researchers, whose job is to find flaws and report them privately to the software’s owners, so they can be fixed before attackers know about them. This is known as responsible disclosure.
In this particular case, the flaws were first reported in August, and the PHP team spent the following months building a fix, with a plan to release it on 21st October. However, details were leaked online before the release – meaning that releasing a fix became a matter of urgency.
Why attacks were expected within 15 minutes
Sansec, a security firm, predicted that mass attacks would start within 15 minutes of the fix being released.
It sounds backwards – surely the release of a fix makes things safer? And yes, it does. But the code released to fix the vulnerability also acts as a map to the vulnerability itself – which will still be present on any site that is yet to update its PHP version.
From the moment a fix is released, it’s a race between attackers understanding and exploiting the vulnerability, and website owners applying the fix. In this case, the leaked information gave attackers a head start.
Why we can expect to see this happening more often
The vulnerabilities found this time had actually been in PHP for years. Researchers at Wiz explained that proving these flaws could actually be used to attack a website relied on a series of exceptionally complicated steps, but that advanced AI models had substantially lowered that barrier.
Amazon’s own security team has stated that AI makes it cheaper to turn a published fix into an active attack, meaning attackers can act within hours, or even minutes, of details being released.
Because of this, the gap between fixes being released and attacks starting is expected to keep shortening.
“Software patching has got to become a regular discipline that every company has to take.”
Dr Meghan Kumar, CEO of Perceptio Labs, speaking to the BBC
Why this one made the news
A combination of factors led to this one making the news. Firstly, PHP runs a huge share of websites, leaving an enormous number of sites at risk. Secondly, attackers didn’t need to log in to exploit the vulnerability. Thirdly, every version from the last decade was affected. And finally, details about the vulnerability leaked before the fix was ready.
The potential scale and severity of this vulnerability were so great that both the UK’s National Cyber Security Centre (NCSC) and the US government’s cyber security agency (CISA) advised businesses to be ready to apply the fix immediately. CISA advised taking older sites, or sites that couldn’t be updated promptly, offline, and the NCSC advised businesses to consider doing the same.
What happened for our clients
How quickly we were able to protect each site came down to one thing: the version of PHP it was running.
- Sites on recent, supported versions were updated within an hour of the fix being released. Fortunately, most of our clients are on our quarterly update cycle, so this was the case for them.
- Sites on older versions, such as PHP 7.4, no longer get official updates, but thankfully in this case PHP did release a patch that could be applied – something that doesn’t always happen. The fix for these versions had to be applied manually by rebuilding PHP from source, so it took longer.
- Sites on very old versions, such as PHP 5, had no fix available at all. For their own protection, we put them behind a firewall – effectively taking them offline – until their owners approve an upgrade.
Upgrading PHP from version 5 to version 8 is a monumental task – it’s applying a decade’s worth of changes in one go, rather than step by step as intended. Parts of the site are likely to break and need rebuilding, which takes time. Not only does this mean a lot of downtime for the site, but it’s also likely to be costly.
The lesson: little and often
Keeping your software up to date doesn’t feel like an exciting thing to spend money on – there’s nothing new to look at at the end. But this week has highlighted just how crucial it is. As Dr Meghan Kumar, CEO of Perceptio Labs, told the BBC: “Software patching has got to become a regular discipline that every company has to take.”
Sites that were kept up to date were protected within the hour, with minimal disruption, and customers were not affected. Sites that had been left for years faced a choice between going offline and suddenly finding the budget and time for a large, urgent update.
Small, regular updates are almost always cheaper and less disruptive than chancing it and dealing with problems as they arise.
What you can do
Knowledge is power, and finding out this information takes a single email and costs nothing. Ask whoever looks after your website:
- Which version of PHP is my website running on?
- Is this version still receiving security updates, and until when? PHP 8.1 and older no longer do.
- When is the next update planned, and what does it involve?
If you aren’t sure who looks after this for you, your hosting company is a good place to start.
If the answer is an old version – don’t panic, but do make a plan. Ask whether your site has been protected against this week’s flaws – and if not, what the options are.
Need a hand?
If you’re a Grizzlyware client, we’ve already been in touch about your site. If you haven’t received an email, contact us at [email protected].
If you’re not sure where your website stands, call us on 01637 222001 or get in touch, and we’ll help you make a plan.