A bad week for WordPress. Why our sites didn't care.

It's been a bad week for websites. If yours runs on WordPress, you've probably had a worried email about it already. Ours didn't care. None of the sites we build and run uses WordPress or PHP, the language it's written in, so there was nothing to patch, nothing to restore and nothing to take offline. Here's what happened, what to ask about your own site, and how we keep ours safe.

What happened

A flaw in PHP, the code behind about 70% of the world's websites, WordPress included (21 October). It lets a stranger take over the server a website runs on, with no password needed. From there, as Professor Alan Woodward told the BBC, "they can steal data". That's everything your site holds: your customers' names, addresses, phone numbers, orders, bookings, messages and logins. The US National Security Agency said it gives attackers "a direct path to the server's file system or database".

It's big: Professor Woodward puts it at around 30 million websites. Governments told anyone who couldn't fix it straight away to take their sites offline, and Finland's government, Edinburgh council and even parts of the BBC did, along with government sites across Europe (Reuters). Hackers started trying it days before the fix was out, and Amazon and Cloudflare are fighting off attacks on it right now. Every website still running unpatched PHP is a target.
A popular SEO plugin shipped with a back door (15-16 October). For about eleven hours, anyone downloading Rank Math PRO got a copy with a hidden way in for attackers. Sites that installed it are being told to restore from a backup.
A backup plugin was used to break into sites (18-19 October). Attackers got hold of the keys UpdraftPlus uses to manage sites remotely, and spent 18 hours quietly adding hidden admin accounts to sites. It's installed on over four million sites.

A timeline of 15 to 22 October: Rank Math PRO ships with a back door on the 15th and 16th, the first attack on PHP on the 17th, UpdraftPlus keys stolen on the 18th and 19th, and PHP2Shell fixed on the 21st as governments take sites offline. Sites we build: nothing to do.

The last two weren't bugs. The plugins were fine; the attackers got into the update system, and sites installed what they were sent because it looked genuine.

If your site runs on WordPress

You don't need to be technical. Send whoever looks after your site these questions:

Is our PHP version up to date with the fix released on 21 October?
Do we use UpdraftPlus? If so, have you deleted its UpdraftCentral keys?
Do we use Rank Math PRO? Was version 3.0.123 ever installed?
Are there any admin or editor accounts on the site that we didn't create?
Do we have a backup from before 15 October, kept somewhere separate from the site?

A good web firm or host will have clear answers, and probably got there before you asked. If the answers are vague, that tells you something too.

Enterprise-grade security, at small business size

WordPress is popular for good reasons. It's cheap, it's familiar, and there's a plugin for everything. But a typical small business site is WordPress plus a dozen or more plugins from a dozen different companies, each updating itself on its own schedule, and each one a possible way in. That's what went wrong this week.

We build the way banks and big companies build, and every site we look after gets all of it as standard:

Layers of protection around a site's code: Cloudflare stopping attacks at the edge, encrypted connections, an ISO 27001 data centre in the UK, and a sealed box holding just the site. The code itself is scanned, tested and reviewed on every change, backed up in the UK, watched around the clock, with a full audit trail.

No WordPress, no PHP, no plugins. Every site is our own code, written in Go, the language Google built for serious online systems. Nothing installs itself, nothing updates itself overnight, and there's no third-party plugin for anyone to hijack.
Your data stays in the UK. Our customers' sites and every backup of them are stored in the UK, and nowhere else.
Certified data centres. Those sites live in data centres certified to ISO 27001, the international gold standard for information security, plus ISO 27017 and 27018 for cloud security and protecting personal data. They're run by one of Europe's largest cloud providers, and it's European-owned.
Protected by Cloudflare. Every visitor reaches the site through Cloudflare, the security network trusted by more than a quarter of the world's websites. Known attacks and floods of junk traffic are stopped before they get anywhere near your site.
Encrypted, everywhere. Every connection uses today's strongest encryption, with the older, weaker kinds switched off, and browsers are told never to connect any other way. The passwords and keys behind the site are stored encrypted, never in plain text.
Security scanning on every change. Static analysis tools read every line of our code looking for the classic security mistakes: commands sneaked into a database, unsafe handling of files, weak encryption, passwords left in code. Every component we build on is checked against the Go team's official database of known vulnerabilities, and the check is smart enough to tell whether we actually use the vulnerable part, so a real problem never gets lost in the noise.
Reviewed and approved by people. On top of the machines, every change is reviewed and signed off before it goes anywhere.
Tested, every single time. Each site has its own suite of automated tests that runs on every change, and if a single one fails, the release simply won't build. Nothing broken reaches your customers, and an old problem can't quietly creep back.
A sealed box. Your site runs in a container holding just that one program, with none of the tools an attacker would want once inside.
Updated on purpose. Everything the code relies on is locked to a known, checked version, and we move it forward deliberately and often, never left to update itself or go stale.
A full audit trail. Every change has a ticket, a review and a sign-off, and every release is recorded. We can always say what changed, when, and who approved it.
Backed up automatically, to a separate place, so a bad day is a quick restore, never a rebuild.
Watched around the clock. If a site slows down or stops responding, we know about it, usually before anyone else does.

The people behind it

Between us, the team has decades of experience building and running software for enterprises, blue-chip companies and regulated industries, where security, audit and uptime aren't optional extras, they're the job. I've spent 25 years doing it myself, as CTO of two software businesses that were both sold, and on regulated banking work including FCA Consumer Duty.

Everything above is that same best practice, brought to small businesses. You get the standards a bank would insist on, without needing to know any of the detail, because looking after it is our job.

Ours had nothing to do

While plenty of website owners spent this week chasing their web firms for answers, our customers didn't have to give it a second thought. No system is perfect, and we'll take every fix that comes along.