What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619), the server-side programming language that powers roughly 70% of websites — including every WordPress site on the internet. Both flaws let an attacker run their own code on a web server without needing a password. They scored 9.2 out of 10 on the CVSS v4.0 severity scale, which is about as bad as security flaws get. The PHP Foundation shipped fixed versions on 21 October 2026.

How serious is it, actually?

Serious enough that the advice from the NSA and the UK's National Cyber Security Centre was blunt: patch your server immediately, and if you can't, take the website offline until you can. That's why the week looked the way it did:

  • More than 30 UK government services went offline as a precaution, including the Office for Budget Responsibility.
  • Germany, France, the Netherlands, Finland, the Czech Republic and Japan all took public sites down — everything from the Port of Rotterdam to Japan's National Tax Agency.
  • Orange, the telecoms giant with 179 million customers, suspended access to PHP-dependent services across 65 countries.
  • Cloudflare's chief executive told Sky News the company was seeing "millions of attempted exploits across our network every single minute".

The scale comes from PHP's reach. It isn't exotic software — it's the plumbing behind WordPress, most contact forms, and the majority of the small-business web. One flaw in PHP is a flaw in tens of millions of sites at once.

What makes this one historic is its age. The flaws had been present in every version of PHP since version 5, released in 2004. For 22 years they were too difficult to exploit for anyone to find practical attacks. That changed recently — more on that below.

Is your website at risk?

Your site is only exposed if all three of these are true:

  • Your site runs PHP. WordPress, Drupal, Joomla, Laravel, most "managed hosting" site builders, anything with a server-powered login form. A static site — plain HTML served straight from a host like Netlify — has no PHP to attack.
  • The server hasn't been patched since 21 October. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your server runs anything older — and especially anything at 8.1 or below, which no longer receives security updates at all — it needs work.
  • Nobody has applied the patch for you. Managed WordPress hosts usually patch the WordPress application itself, but the PHP runtime underneath is often the site owner's problem — or nobody's.

Worth saying clearly: this is not a WordPress bug. WordPress published a statement confirming the flaw isn't specific to its software, but told site owners to make sure their servers are patched and to work with their hosting companies. Millions of WordPress sites are fine because they sit on patched servers. Millions more aren't, because nobody checked.

What to do this week: a five-step check

  1. Find out who manages your server. You, an agency, or a hosting company? If you don't know, the honest answer is "nobody", and that's the first problem to fix.
  2. Ask them one direct question: "Has our PHP been updated to a patched version — 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — since 21 October?" A competent host or agency answers in one sentence, with a version number.
  3. Check your PHP version yourself if you can. Most control panels show it under PHP settings. Anything below 8.2 needs updating; anything on 8.1 or older needs a proper migration plan, because those versions get no security fixes at all now.
  4. If the answer is slow or vague, ask for the site to be taken temporarily offline rather than left up and exposed. A day offline is cheaper than a hacked site — it's exactly what governments did this week.
  5. Once patched, change the passwords on the site's admin accounts as a precaution. Five minutes, and it closes off the cheap attacks.

Questions worth asking any web host or agency

If this week proved anything, it's that most business owners have never been told what their site runs on. These five questions separate the outfits that manage infrastructure properly from the ones that sell you a template and vanish:

  • What server language and version does my site run on, and who patches it?
  • Did this week's PHP update apply to us, and was it applied the day it came out?
  • Do we get told when a security issue affects our site — before we read about it in the news?
  • Is any part of our site exposed to the internet that doesn't need to be?
  • Can you show me, rather than tell me?

Why no Vesica client site needed patching

We'll declare the obvious conflict of interest up front: we build websites, and we build them a particular way, so take this as an explanation rather than a sales pitch. Every site we build and host is hand-coded and served static — plain HTML, CSS and a little JavaScript, with no PHP runtime anywhere. There is no WordPress login page to attack, no PHP interpreter to exploit, nothing for this flaw to touch.

When the news broke we didn't just assume that — we checked. On 22 October we ran live probes against all six properties we run (our own site plus five client sites): every one came back on a static hosting platform with no PHP signature in its headers, and requests to .php addresses and WordPress login paths returned 404 — nothing executed, because nothing exists to execute. Our own server runs zero PHP packages and has no PHP processes. There was nothing to patch, and we could prove it in minutes rather than promise it.

That's the structural point worth taking away: the most secure code is the code that isn't there. A static site gives up nothing a small business actually needs — the interactive bits (contact forms, bookings, reviews) run through small, isolated services instead of one big PHP application — and in exchange you get fewer moving parts, faster pages, and a much smaller attack surface. It's the same reasoning behind our guide to choosing a website builder for a small business: decide what the site genuinely needs, then run only that.

AI found this flaw — and that cuts both ways

The strangest part of this story is who found the flaws: nobody had, for 22 years, until AI did. One flaw surfaced through OpenAI's "Patch the Planet" initiative, in which a security firm used frontier AI models to hunt for bugs in open-source software. Google's Wiz team, working separately with its own AI security tooling, found more. Both got there before any criminal group did, and both worked with the PHP Foundation on coordinated fixes before publishing anything.

So AI handed the internet an early warning it would never otherwise have had. But Wiz's researchers were direct about the flip side: these flaws stayed harmless for two decades partly because exploiting them was genuinely hard. AI removes that barrier — it can adapt an exploit to different PHP versions and server setups in moments. From now on, assume any published vulnerability will be attacked fast, because "millions of attempts a minute" is what day one of a disclosure looks like now.

For a small business the practical conclusion is boring but firm: the window between "flaw announced" and "attacks begin" is now hours, not weeks. Whoever manages your server needs to be someone who acts inside that window.

Quick answers

Is WordPress safe after the PHP2Shell flaw?

WordPress itself is safe when the server it sits on is patched. The flaw is in PHP, not in WordPress — but because WordPress runs on PHP, unpatched hosting leaves a WordPress site exposed. Check with your host that PHP has been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer.

How do I check which PHP version my website uses?

Most hosting control panels display it under PHP settings or "PHP configuration". If you can't find it, email your host and ask — and ask when it was last updated. If you don't know who your host is, a WHOIS lookup on your domain will point you to the name servers.

Do static websites need to worry about PHP vulnerabilities?

No. A static site has no PHP runtime on the server, so PHP vulnerabilities give an attacker nothing to attach to. The trade-off is that static sites need separate services for anything dynamic — which is how we build anyway.