PHP vulnerability: is your business website at risk?

On 21 October 2026 the UK's National Cyber Security Centre told organisations to patch two critical flaws in PHP or consider taking their websites offline. Plenty did. If you run a trades firm, a garage, a cleaning company or a hospitality business, there's a fair chance your website runs on PHP too. Here's what happened, how to check whether you're exposed, and what to do this week.

What actually happened

Two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell", were disclosed this week. The PHP security team rated both Critical, scoring 9.2 out of 10.

In plain English: under the right conditions, an attacker can run their own code on your web server without logging in and without anyone clicking anything. That is the worst category of web vulnerability there is. Once someone can run code on your server, they can change your site, plant malware, or read whatever data sits on it.

The flaws were found by security firms Wiz and Calif using AI models, then reported privately to the PHP team so fixes could be prepared before details went public. Wiz says every PHP version back to 5.4 is affected by at least one of the two issues, and it demonstrated working attacks against current installations of WordPress, Drupal and Joomla.

The response was immediate. Edinburgh, Oxford and Bristol councils pulled their sites. So did government services in Finland, France, the Netherlands and Denmark, alongside universities, hospitals, the Port of Rotterdam and parts of Wikipedia's infrastructure. Attackers moved just as quickly, with security firms reporting attack attempts in the millions.

Why this matters for a small business

PHP is the programming language behind WordPress, WooCommerce, Joomla, Drupal, Magento and a long tail of bespoke sites. Wiz estimates PHP powers roughly 70% of websites. That doesn't mean 70% of sites are vulnerable, but it does mean this isn't a niche problem.

For most firms with 5–50 staff, the website is a WordPress site a local agency built a few years ago, sitting on shared hosting, which nobody has logged into for a year. That's precisely the profile most at risk, because nobody is watching it.

If a site like that is compromised, the damage is practical, not theoretical:

  • Lost enquiries. Your contact form stops working, or quietly sends leads somewhere else.
  • Google warnings. If your site starts serving malware, browsers and search results flag it. Customers see a red warning page instead of your business.
  • Data breach obligations. If customer or job data on the site is exposed, UK GDPR may require you to report it to the ICO within 72 hours of becoming aware.
  • Downtime. Even a precautionary takedown costs you enquiries for every hour it's offline.

One point catches people out: updating WordPress, your theme or your plugins does not fix this. The flaw is in PHP itself, which runs underneath WordPress on the server. The fix has to happen at server level.

How to check if you're exposed

This takes about 15 minutes and a phone call or two.

  1. Find out what your site runs on. If you or your staff log in at yoursite.co.uk/wp-admin, it's WordPress, which means PHP. If you're not sure, ask whoever built it.
  2. Find out who is responsible for the server. On shared or managed hosting, that's your hosting company. If your agency set up a server for you, it's them, or possibly you.
  3. Ask one question, in writing. Email your host or agency: "Has the PHP version on my site been upgraded to a patched release (8.5.12, 8.4.27, 8.3.36 or 8.2.35), and when?" A good host will answer within hours. Vague reassurance is not an answer.
  4. Treat old versions as urgent. If your site runs PHP 8.1 or older, there's no official release from the PHP project. Some Linux distributions and hosts are backporting fixes, but the real answer is getting moved onto a supported version.
  5. If you can't get a clear answer today, take the site down. That's the NCSC's own advice. A simple holding page with your phone number costs you far less than a compromised site.
  6. After patching, check for damage. Ask your host to review server logs for suspicious activity. Look for admin users you don't recognise, unexpected redirects, or pages you didn't create.

Why the Campbell site stayed up

campbellconsultancy.co didn't go offline this week and didn't need emergency patching. That isn't because we were quicker than everyone else. It's because there's no PHP in it.

  • The site is built with Astro. Every page is generated into plain HTML and CSS before it's published. When you visit, you're sent a finished file. There's no PHP engine assembling the page on request, so there's nothing for this attack to target.
  • It's hosted on Cloudflare Pages. The finished files are served from Cloudflare's global network. We don't run a web server, so there's no server software of ours to patch in the middle of the night.
  • The code lives on GitHub. Every change is version-controlled. If anything ever goes wrong, rolling back to the last good version takes seconds.
  • Forms go to a dedicated form service. Enquiries are handled by a specialist provider rather than a script running on our own server.

That's the standard set-up for every website we build for clients, and this week is a good illustration of why.

What static doesn't protect you from

To be straight about it: a static site isn't immune to everything. The remaining risks are mostly about accounts rather than servers:

  • Someone stealing the login for your domain registrar, hosting account or code repository. Two-factor authentication on all three is non-negotiable.
  • Third-party scripts such as analytics, chat widgets or booking tools, which run on your pages and need choosing carefully.
  • Your domain's DNS settings, which control where your site and email point.

The difference is the size of the target. With a static site, what's left is account hygiene you can sort in an afternoon. With a self-managed PHP site, you're also on the hook for emergency server patching whenever the next flaw lands.

Should you rebuild your site?

Not this week. This week, patch or take down. Make the rebuild decision afterwards, on its merits.

A rebuild makes sense if:

  • Your site is essentially a brochure: services, areas covered, reviews, contact details. It doesn't need logins, member areas or complex functionality.
  • Nobody actively maintains it, and you only found out it runs on PHP because of this article.
  • It's on PHP 8.1 or older, or your host couldn't tell you what version you're on.
  • It's slow, especially on mobile, which is where most of your customers find you.

A static site of that kind also typically costs nothing to host on Cloudflare's free tier, which removes a monthly bill as well as a security headache. If you want the numbers, we've written up what affordable web design for a small business actually costs.

Keeping WordPress makes sense if your team updates content daily, you rely on plugins that genuinely earn their keep, and your host patched within hours this week. A host that responsive is worth keeping.

The short version

  • Two critical PHP flaws were disclosed on 21 October 2026. The NCSC says patch or take sites offline.
  • WordPress, WooCommerce, Joomla, Drupal and Magento sites are all in scope.
  • Updating WordPress or plugins does not fix it. PHP itself must be upgraded on the server.
  • Email your host today and ask for the patched version number in writing.
  • If you're on PHP 8.1 or older, or can't get an answer, take the site down until it's fixed.
  • Static sites built with tools like Astro have no PHP to attack, which is why ours stayed up.

See how we build fast, low-maintenance business websites.

Not sure what your site runs on?

Book a 20-minute call. We'll tell you what it's built on, whether this affects you, and what to do about it.

Book a discovery call → Submit a project brief →
Free ops checklist