Reacting to PHP2Shell

Weeks like this one are when you find out whether anyone is actually looking after your site.

On Tuesday 20th October, the PHP security team announced an emergency release for the following afternoon. Two critical flaws had been found in PHP itself, both rated 9.2 out of 10, and details had leaked online before the planned disclosure.

By the time the fixes landed at 14:00 UTC (3pm here in Ireland), the bugs had a name, PHP2Shell, and were making the news. Governments were taking websites offline. Headlines were counting vulnerable sites in the millions.

We look after a lot of websites, and most of them run on PHP. We monitor emerging threats closely, so we new what was coming and cleared our schedules.  Our job was to get every server we’re responsible for patched, quickly and calmly, and make sure every client heard from us before they read about it somewhere else. Within hours of the patches landing we had applied the patch everywhere it could be applied, and by the next morning we had full patch coverage across our entire client base. This is what that looked like from the inside, and what I think it says about looking after websites properly.

What the vulnerabilities are

PHP2Shell is two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are memory-handling bugs in the PHP interpreter, one triggered by running out of memory, the other by how PHP cleans up after a fatal error, as Unit 42 explains. In the worst case, either could let someone with no login run their own code on your server.

An important detail for website owners to understand is where the bug resides. Unlike the majority of vulnerabilities we encounter It isn’t in WordPress, a theme or a plugin. It’s in PHP, the underlying language. CISA’s alert covers every common way of running PHP on a web server. Updating your plugins does nothing here; Wordfence warned that WordPress auto-updates wouldn’t fix it. The fix is a new PHP build: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

If your site is on PHP 8.1 or older, there’s no official fix from PHP, because those versions are out of support. In practice, unofficial patched builds for older versions appeared within a day, but the right answer is still to upgrade.

Easier said than done on unmaintained systems, which is yet another reason that regular maintenance is critical for any website that needs to keep running – patching a php version is a lot more straightforward than upgrading a whole web server and then making an ancient website run on it.

The headlines v the evidence

The coverage online leaned towards alarming. News outlets ran with millions of websites at risk, quoting a figure of 22.6 million exposed instances that, read carefully, counts neither unique websites nor actual breaches. Agencies told anyone who couldn’t patch to take their site offline and government sites in the Netherlands, Finland and France went dark, purely as a precaution.

The technical picture has been more mixed, and it’s still being argued about. Here’s what we know:

Attacks are being attempted. Amazon claims that they saw an attempt on 17 October, four days before disclosure, and Cloudflare reported attempts climbing into the millions within a day of the release.

Most attacks don’t seem to work. The public exploit code crashes PHP far more often than it takes over a server. Sophos retracted a report of successful exploitation, and Google said it had no evidence of wide-scale compromise.

This doesn’t mean it’s harmless. CISA added both CVEs to its Known Exploited Vulnerabilities list on 26 October. Some researchers argue the bug is hard to weaponise rather than overhyped, and that’s a gap skilled attackers will close given enough time.

Some of the reporting was borderline hysterical and ill informed, and the real-world impact is still debatable, but that debate didn’t change what we had to do. Even a failed attack could stta a PHP worker, which is downtime for a client. And “probably hard to exploit” isn’t a phrase I want to rely on for someone else’s business.

What we did about it

For us, the two days went roughly like this.

We got ready before the release. Once PHP announced the time of the release, we worked out which servers and sites needed attention and in what order and made sure we were available and our systems were ready.

We told every maintenance client before the patch dropped. A personal note to each one saying we’d seen the warning, we had a plan, and their site would be fine. When the news says “millions of websites at risk”, the natural question is whether yours is one of them. We wanted them to hear from us first, with a straightforward answer.

We patched as soon as the fixes landed. Servers on supported PHP versions got the new builds the same afternoon. Sites on unsupported PHP versions or older servers were upgraded rapidly.

Within hours of the patches landing, every server we’re responsible for was fully secured and operational.

What PHP2Shell says about website maintenance

Most of the time, website maintenance is invisible. Updates go on, backups run, nothing happens. Weeks like this one are when you find out whether anyone is actually looking after your site.

Three things stood out for me:

Nothing beats a trained professional watching your site. Passive maintenance tools or CMS auto-updates couldn’t fix this. Someone had to know which PHP version each site runs on, and have the access and the skills to change it safely.

Neglect is a real problem. VirusTotal counted roughly 187,000 servers still announcing PHP 7.4, and around 119,000 on PHP 5.4. None of those got an official fix this week, and are unlikely to have been patched at all, given their evident neglect. That’s a lot of sites using the ‘forget about it and hope for the best’ strategy.

Calm is part of the service. Global panic gets clicks, but is stressful for clients, even when the real risk to them is low. A clear message from the people who look after your site is worth something, I think.

If you’re not sure who would have patched your website last Wednesday, or what version of PHP it runs on, that’s a conversation to have now, before the next incident hits.

Build a maintenance plan with Maverick Labs, or book a 15-minute consultation with our team.