Old Isn’t the Same as Legacy
Originally published at https://selfhostedhome.co.uk on October 23, 2026.
When the PHP2Shell news broke this week, my first thought was the usual thing: PHP is old web tech, it’s everywhere, with plenty of it sitting inside organisations that would never dream of touching it. Government departments, councils, small businesses, that sort of thing. It was the reason 32 UK government websites were taken offline for patching.
The same day, the government launched its Be Ready campaign, urging every household to keep three days’ worth of food and water in the house. Officially about weather, cyber threats and hostile states, and nothing to do with PHP. But Government websites going dark and “ stock up for 72 hours” in the same news cycle is too amusing.
This post is about the PHP exploit and perceptions of older technology, not the Armageddon scaremongering.
What actually happened
On 21 October 2026 the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026–109618 and CVE-2026–109619, which have been nicknamed PHP2Shell. Both let an unauthenticated attacker run code on a server remotely, and both sit in the PHP runtime itself — not in some plugin or framework.
The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches no longer get official updates, although minimal source backports were published for 7.4, 8.0 and 8.1.
Updating your CMS or its plugins won’t touch the runtime underneath. The PHP version itself has to be updated. That includes any containers or managed hosting you might have forgotten about.
Old versus legacy
Old technology and legacy technology aren’t the same thing.
Old technology can be perfectly good, well understood and maintainable. Legacy technology is something an organisation can no longer easily change, whether it’s good or bad. PHP is still actively maintained and the project turned fixes around quickly. The trouble is the mass of applications built on top of it, many written years ago by old coders who’ve since retired to the Costa del Sol 🏖️
Unix is the prime-example
We can be quick to label things as “legacy” just because they’ve been around a while. Unix was conceived in 1969 and first released in 1971. More than half a century later its descendants run a huge share of the world’s servers, phones and networking kit. I spent a good chunk of my career working with Linux, which carries that design thinking forward, and I still use it daily in retirement.
Get RA Bosomworth’s stories in your inbox
Join Medium for free to get updates from this writer.
Nobody calls Unix legacy in the pejorative sense — it’s been looked after, kept simple and allowed to evolve. Age on its own isn’t the problem. A decades-old application that’s fully documented, maintained and understood is in far better shape than something built last year, largely written by AI, where nobody has the remotest idea how it all fits together. I’m a big fan of AI, but code nobody understands is a risk whoever or whatever wrote it.
Not my problem these days
I haven’t touched PHP since I supported WordPress about 15 years ago, so none of this affects my own home-hosted systems. It would have been a very different story back then. I was looking after big WordPress sites, and a flaw like this would have meant working out which servers were running what, and how fast they could be updated without breaking something.
Where Cloudflare fits in
I publish all my sites through a Cloudflare tunnel and I wondered whether that would offer any protection against something like this. The answer is, some — but not for the reason you might think.
The tunnel itself means I have no inbound ports open on my home network and my server’s actual IP address isn’t exposed. Nobody can scan or hit it directly. That’s a real benefit. But the tunnel just carries traffic through, and a malicious request to a public hostname gets delivered like any other.
The part that helps with something like PHP2Shell is Cloudflare’s web application firewall (WAF), which looks at requests coming in through proxied hostnames. Cloudflare reportedly deployed rules for the known exploit patterns before the flaws were made public. I don’t know if all plans get those rules, so it’s worth checking your own dashboard rather than assuming.
A WAF isn’t a cure, though. It can only block what it recognises, and the PHP developers themselves have said that no mitigation fully stops these attacks and that patching is the only permanent fix. It’s a useful extra layer that buys time, but not a reason to skip the update.
Even so, I think a Cloudflare tunnel is totally worth using irrespective of this particular issue. Closed inbound ports, a hidden origin and a filtering layer in front of whatever you’re hosting are all good habits for self-hosting, and the next awkward vulnerability is probably already on its way.
The takeaway
The vulnerability itself is a patching job: update the runtime, check where else PHP is hiding, and move on. The bigger lesson is that what makes technology risky is whether you can still change it, rather than how old it is. If you can patch it, test it and replace pieces of it when you need to, it can be old and still be fine (like me 😉). If you can’t, it’s a problem waiting for its moment.
shh@home:~$ echo "keep it local"
keep it local
