PHP broke the internet again. Why WordPress should have retired in 2015, and what to build instead

If you run WordPress, Joomla or TYPO3, read this today

The short version first, then the detail. WordPress, Joomla, TYPO3, Drupal, Magento, and most of the booking and shop plugins you can name are all built on PHP. On 21 October 2026 the UK National Cyber Security Centre issued a critical alert for two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. Because the flaw is in PHP, every one of those systems is exposed, not only the old ones. The alert says plainly that any version of PHP is affected.

What can actually happen, in plain words: an attacker gets a direct path to your server's files and database. They can run their own commands, read or steal your data, and change your site, with no password and no login. In practice that means stolen customer records, a hijacked or defaced website, ransomware, or a shop quietly skimming card details from your checkout. If you cannot update immediately, the official advice is to take the system offline until it is fixed. A national cyber authority telling businesses to pull the plug on their own websites is about as serious as these warnings get. There is a second bill after the technical one. If customer data is taken, this is a reportable personal data breach. Under UK GDPR and the EU DSGVO you can be required to notify the regulator within 72 hours and tell the people affected, and the fines reach the higher of 20 million euros or 4 percent of your global turnover. A hacked WordPress site is not only an IT problem, it is a legal and financial one.

If that is your website, patch it today. Then read on, because patching this one flaw does not fix the reason it keeps happening.

The morning the official advice was "take your website offline"

On 21 October 2026 the UK National Cyber Security Centre published an alert about PHP, the programming language that quietly runs a large share of the internet. The headline finding was blunt. The flaws could "allow attackers to execute commands on any web server running PHP", and under the wrong conditions that means "unauthenticated remote code execution". In plain English, a stranger could make your server do what they want, without a password, without logging in, without you noticing.

The part that turned a normal patch notice into a bad week for a lot of IT teams was one sentence: "Organisations using any version of PHP are affected." Not just the old, neglected sites. Any version. And the recommended actions included a line you almost never see in official guidance: if you cannot update or mitigate quickly, "consider taking the system offline until it is fully mitigated."

Read that again. The national cyber authority told organisations that pulling the plug on their own website was a reasonable option. That is how serious this one was.

What actually happened, in plain English

The two issues have the catalogue numbers CVE-2026-109618 and CVE-2026-109619. You do not need the internals, but the shape is worth understanding because it explains why the fix is urgent.

Both are memory handling bugs. One happens when PHP runs out of memory at the wrong moment and then treats half finished, invalid data as if it were valid. The other is stale state: information from one visitor's request can linger in a shared worker and get picked up by the next visitor's request before it is cleaned up. When you can nudge a program into using memory it should not trust, you can sometimes steer it into running your instructions instead of its own. That is the path from "a weird crash" to "remote code execution".

PHP released a security update and some hardening steps. The honest summary for a business owner is simple. If you run anything on PHP, it needed patching immediately, and if you could not patch it fast, the official advice was to take it down or isolate it and check whether anyone had already been inside.

Why "any version" is the frightening word

Most security stories are about one product with one bug. This is different, and the difference is the whole point of this article.

PHP powers the majority of the websites on the planet whose server language is known. WordPress, which is built on PHP, runs roughly four in ten of all websites in existence. Add the shop plugins, the booking systems, the membership tools, the countless appliances and control panels that quietly bundle PHP inside them, and you are looking at a huge slice of the web sharing the same foundation.

When everyone builds on the same foundation, a single crack is not your problem, it is everyone's problem at the same instant. Attackers know this. Within hours of an alert like this, automated tools are scanning the entire internet looking for servers that have not patched yet. You are not being targeted because someone hates your business. You are being targeted because a script found your address and your server answered. Monoculture is efficient, and it is exactly why one PHP flaw can ruin thousands of companies' week in parallel.

The part nobody at the WordPress meetup wants to hear

Here is the uncomfortable opinion, and I will own it. PHP and WordPress had their moment, and that moment was a long time ago. By around 2015 the modern alternatives were mature, proven and running serious businesses. Continuing to build new, important systems on the PHP and plugin model after that was a choice, usually made because it looked quick and familiar, not because it was the right long term foundation.

I want to be fair, because fairness is more persuasive than a rant. Millions of WordPress sites run perfectly well. For a simple brochure site it can be a sensible tool. The problem is not that PHP can be written badly. Any language can. The problem is the model that grew up around it: a shared stack that the entire internet runs at once, a website stitched together from forty plugins written by forty strangers you will never meet, running on rented hosting you do not really control, where "secure" depends on dozens of other people patching on time. That is not a bug you can fix. That is the architecture.

So when a once in a few years PHP flaw lands and the official advice is "consider taking your site offline", the right question is not "how fast can we patch". The right question is "why is my business still standing on a foundation the whole internet shares".

Secure by architecture, not by luck

Security is not a product you bolt on at the end. It is mostly decided by how a thing is built. A few principles separate software that is safe because of its design from software that is safe only until the next shared flaw.

Keep the attack surface small. Every plugin, theme and bolt on is another door with another lock fitted by another person. A custom application built for exactly what your business does has far fewer doors, and I know who fitted every one of them.

Give every part the least power it needs. Most real breaches get worse because one compromised component could reach everything else. Good architecture boxes things in, so a problem in one place cannot walk into your database and your customer records.

Watch it while it runs. Every app I operate is wired to live error monitoring. The moment a single user hits a problem, I know which page, which action and where in the code, instead of waiting for an email that starts with "it's not working". Quiet software is not safe software, it is software nobody is looking at.

Own the code. When the work is custom and the code is yours, a fix is a decision you can make today. When your site is a tower of other people's plugins, you are waiting on other people's release schedules while the clock runs.

Why I build on Ruby on Rails

None of this means a modern framework is magic or unhackable. No stack is. Anyone who tells you their software cannot be breached is selling you the next incident report. The honest claim is about blast radius, ownership, maintenance and having a named person who answers for it.

I build on Ruby on Rails because it is a mature, serious framework with strong security habits built into the way you work, not bolted on afterwards. Protection against the classic web attacks is the default, the conventions push you towards doing the safe thing, and the same framework runs some of the most demanding businesses online. Shopify, which handles a very large portion of the world's online checkouts, runs on Rails. GitHub, where most of the world's code lives, runs on Rails. This is not a hobbyist toy.

On that foundation I build three things for clients:

A custom online store you actually own, built on Solidus and Ruby on Rails, instead of renting a themed template that every competitor also uses and that breaks when a shared plugin does.
A SaaS product built to last, with the data model, the billing and the security thought through for the thousandth user, not just the demo.
A modern website that is fast and secure by default, not a pile of plugins held together with hope.

Custom does not mean slow or expensive. I use AI every day to build faster and for a lower price, and I answer for every line that reaches production. Speed is not the risk. Shipping code that nobody understands and nobody owns is the risk.

And it comes with a native app, not a mobile afterthought

Here is the part most web shops cannot offer. Because I build the core of your product properly, with a clean way for other software to talk to it, the same product can ship with a real native iOS and Android app. One codebase, both app stores, your brand in your customers' pockets, sharing the same secure backend as your website. That is not a plugin. That is a product.

A WordPress site cannot hand you that. A custom application can, and when you are already building it properly, adding the app is a step, not a rescue mission.

What to do this week, whether or not you ever hire me

If you run anything on WordPress or PHP, this is the practical list, straight from the official guidance.

Find every PHP system you have, starting with anything facing the internet, including shop plugins, booking tools and any appliance that bundles PHP inside it.
Update to the patched version now. If you cannot, apply the official temporary mitigations, and if you cannot do that quickly, take the system offline until you can.
Assume nothing. If a system sat unpatched and exposed, check it for signs of compromise and hidden backdoors before you trust it again. If that is beyond your team, use an assured incident response provider.

Do that first. It is the responsible thing and it has nothing to do with buying anything from me.

Then, once the fire is out, ask the bigger question. Is rented, shared stack software still the right foundation for the part of your business that actually makes money. For a lot of companies the honest answer is no, and this week was the reminder.

Where this leaves you

Every few years the shared foundation cracks, everyone scrambles, the sites come back, and we all agree to worry about it next time. You do not have to live on that cycle. You can build the important parts of your business on software that is custom, secure by design, actively watched, owned by you, and ready for the web and a native app at the same time.

If this week made you nervous, that is a useful feeling. Let us turn it into a plan.