PHP2Shell: why some websites can't be patched

Since 21 October, attackers have been able to break into a large share of the world’s websites without a password. All it takes is one carefully crafted request to the server, and the first attacks were spotted the same day the flaw was made public.

The flaw is called PHP2Shell. Most websites will be fixed within days, quietly, by their hosting company. Some can’t be fixed that way at all. If your business has a website or customer portal that was built a few years ago and still runs fine, it’s worth ten minutes to find out which group you’re in.

What actually happened

PHP is the software running behind most websites, including anything built on WordPress, many online stores and a lot of custom-built customer portals. Researchers found two flaws in it, CVE-2026-109618 and CVE-2026-109619, that let an outsider run their own commands on the server. Once they can do that, they can read customer data, plant malware or take the site down.

Every version of PHP released in over a decade is affected. The people who maintain PHP released a fix on 21 October, and attacks were seen in the wild the same day.

Why some sites can’t just be patched

The fix was only released for PHP 8.2 and newer. Older versions have stopped getting security fixes, the same way an old phone eventually stops getting updates. For 7.4, 8.0 and 8.1, some Linux vendors and hosting providers patch them on their own; for 7.3 and older, there’s nothing to install at all.

Plenty of business websites still run on those older versions, simply because they were built a while back and nobody has needed to touch them since. For those sites, the real fix is moving to a newer version of PHP, and on an older site that move tends to break things in the places that matter most: the checkout, the booking form, the invoice emails, the connection to another system. Often nobody notices until a customer does.

Your developer can switch off one PHP setting to block some of the attacks while the upgrade is planned. PHP’s own guidance is that it won’t stop all of them.

Why this won’t be the last one

These flaws had been hiding in PHP for over a decade. They were found with the help of AI: the researchers used AI models to find the bugs, build working attacks and check the fix, and did in about a week what they say would previously have taken a team months.

Expect more of these, and sooner. AI is making it much faster and cheaper to find security holes in old software, and attackers have the same tools as the researchers.

Code that has quietly worked for years is now being searched for weaknesses at a pace that wasn’t possible before. The websites that will struggle most are the ones running on software that no longer gets fixes, because when the next flaw is found, they’ll have nothing to install.

What to do this week

Ask whoever looks after your website three questions:

1. Which version of PHP does our site run on? Anything below 8.2 needs an upgrade.
2. Has the 21 October fix been installed, and has PHP been restarted so it actually takes effect?
3. Could anyone have got in before the fix? Attacks started on day one, so it’s worth checking for unfamiliar files and admin accounts.

If your site runs on 8.1 or older, treat the upgrade as a small project with its own testing. Do it on a copy of the site first, test the parts that make you money, and keep a way back in case something goes wrong. That’s what a migration risk audit is for. And if this is the first time you’ve wondered what your website runs on, the signs your working system has quietly become a liability are worth a read too.

If you don't have anyone looking after your website, or you're not sure who to ask, reach out to us. We'll check whether your site is exposed, tell you plainly what needs to happen, and fix it if you'd like us to.