· security · 4 min read

PHP2Shell: the critical PHP vulnerability that should have every website owner checking for updates

Two critical, unauthenticated remote code execution flaws in PHP were patched this week. Here's what happened, why it matters even if you've never touched a line of code, and why ongoing website maintenance isn't optional.

Two critical, unauthenticated remote code execution flaws in PHP were patched this week. Here's what happened, why it matters even if you've never touched a line of code, and why ongoing website maintenance isn't optional.

If you run a website, there’s a very good chance it’s built on PHP, whether you know it or not. WordPress, Joomla, Magento and a huge chunk of the custom-built web all run on it. That’s exactly why the last few days should matter to you, even if “PHP” means nothing to you day to day.

What actually happened

On 21 October 2026, the PHP project released emergency patches for two critical vulnerabilities, nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 out of 10 (CVSS v4.0) — about as severe as it gets — and both allow unauthenticated remote code execution. In plain English: an attacker doesn’t need a password, a login, or any access to your site at all. They just need it to be running a vulnerable version of PHP, and they can potentially run their own code on your server.

  • CVE-2026-109618 — remote code execution triggered through memory corruption when PHP runs out of memory mid-request.
  • CVE-2026-109619 — remote code execution caused by stale internal “global state” data hanging around after it should have been cleared.

To add to the chaos, details leaked a day ahead of the planned disclosure, and security researchers reported seeing exploitation attempts against honeypots within hours of the fix going live. Two days later, on 23 October, PHP published a third, narrower advisory — CVE-2026-115560 — affecting a more specific setup, as a reminder that this story is still moving.

The fix is straightforward on paper: upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. If you want a quick sanity check on a server you manage, php -v will tell you what you’re running.

The uncomfortable bit

Those patches only exist for PHP 8.2 and newer. If a site is still sat on PHP 8.1, 7.4, or older, there is no patch. And PHP 7.4 in particular is still sitting under a surprising number of live business websites, because it quietly kept working for years after it stopped receiving security updates. “It still works” and “it’s still safe” stopped being the same sentence a long time ago. For those, the only real fixes are isolating the system, applying partial mitigations, or finally doing the upgrade that’s been put off — none of which happen on their own.

UK’s National Cyber Security Centre and CERT-EU have both gone as far as recommending that anything internet-facing which can’t be patched quickly should be taken offline until it can be. That’s not a sentence security agencies use lightly.

Why this isn’t really a “PHP story”

This happens with WordPress plugins, with jQuery, with SSL libraries, with server software — PHP just happens to be this month’s headline. The pattern repeats because websites aren’t appliances you plug in once and leave. They’re built on layers of software that are constantly being found to have flaws, and the only defence is someone actually watching for it and acting when it matters.

A vulnerable, unpatched site isn’t just a technical inconvenience. It’s how sites end up quietly serving malware, get blacklisted by Google and browsers overnight, lose customer trust, or — if customer data is involved — turn into a very real data protection problem under UK GDPR.

What to actually do about it

You don’t need to understand memory corruption to act on this sensibly:

  • Ask whoever hosts or built your site what PHP version it’s running, and whether it’s been patched.
  • If you’re on WordPress, Tools → Site Health will usually flag an outdated PHP version.
  • If nobody can give you a straight answer, that’s the real vulnerability — not the CVE.

If nobody’s actually looking after your site, I can help

Alongside insurance broking, I also build and maintain websites — and this is exactly the sort of thing that gets missed when a site was built once, launched, and never looked at again. Whether that’s auditing what you’ve currently got, getting a neglected site patched and back on solid ground, or building something bespoke from scratch that’s actually looked after, get in touch and I’ll be happy to help.

Sources:

Share:
Back to Blog