We're Officially PHP-Free. Here's What October Taught Us (So Far)

The week of 19 to 24 October 2026, Monday to Saturday, brought a steady run of serious security news across the industry. If you missed it, our review of that week covers the detail. The short version: in several cases, attackers moved before fixes did.

A week like that does not send us back to the drawing board, but it does sharpen the lines already on it. It is one thing to hold a principle, and another to watch, case by case, what happens where that principle is missing. So rather than list technical steps, we want to explain the principles we work by, because for you as a customer the approach matters more than any single update. One of those principles has just reached its milestone: we are now officially PHP-free.

Why is patching after the fact a losing race?

For years, the standard advice was simple: patch quickly and you will be fine. The trend was already running against that advice. Google's Mandiant team measured the average time between a vulnerability becoming known and its exploitation: 63 days in 2018 to 2019, 32 days across 2021 and 2022, and five days in 2023, averaged with outliers removed.

Five days is the figure from 2023, before AI tools became part of everyday software work. This month gave us a fresh measurement of the race, taken from three different vantage points around the PHP2Shell disclosure of 21 October 2026.

Amazon's threat intelligence team saw a PHP2Shell exploitation attempt on 17 October, four days before public disclosure, and says that once the embargo lifted and the patch was released, more proof-of-concept exploits appeared within hours. F5 Labs saw the first PHP2Shell scanning more than five hours before the two CVEs were published, and within hours of disclosure its sensors were recording thousands of exploit attempts. Cloudflare's CEO, Matthew Prince, said on 22 October that Cloudflare saw thousands of attempts before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions by the time he posted. These were attempts, not confirmed break-ins, but they show how quickly the doors were being tried: the window is now measured in minutes and hours, and for some it closed before the patch even existed.

Exploitation before any fix exists is not a rarity either. In 2023, 70% of the exploited vulnerabilities Mandiant tracked, 97 of 138, were exploited as zero-days, meaning before any fix existed at all.

If exploitation can start before a patch is available, and arrive in volume within minutes of one, then patching, however disciplined, cannot be the whole plan. A defender who relies on it alone has entered a race that is often decided before it begins. So we assume the race will sometimes be lost, and we design for the losing. That assumption turns into three questions. While a flaw is open, how much of our systems can be hit? If something is hit, how much can be lost? And once a fix exists, how fast can we recover and close the gap? Every principle we hold answers one of those questions, and everything below is organised around them.

Why do we remove software instead of patching around it?

Start with the first question, how much can be hit. Every organisation accumulates software that has aged badly: tools whose maintainers have moved on, components stuck on old versions because something else depends on them, code nobody wants to touch. The common response is to wrap such software in workarounds and firewall rules and hope for the best.

We take a different view. Software that cannot be kept current is removed, not patched around. We do not keep it alive with temporary fixes, because a temporary fix on unmaintained code is a promise that will eventually be broken. Either a component can be updated for as long as we run it, or it does not run at all.

Why do workarounds fail? Because a workaround only blocks the flaws that are already known. Unmaintained software does not stop having weaknesses the day its maintainers walk away. Researchers and attackers keep finding new ones, year after year, and now nobody is left to write the fixes. Each discovery forces another rule, another filter, another layer bolted on top of the last, and the pile grows more fragile with every addition. Sooner or later a flaw appears that no outer layer can screen out, or two layers interfere with each other, and the protection quietly gives way. A workaround buys time, and on abandoned code there is nothing useful to spend that time on, because the underlying problem is never going to be fixed.

Think back to the race above, now run in minutes and hours. Against maintained software, the race is brutally short, but at least it can be run. Against abandoned software, there is no race at all, because the fix that should end it will never arrive. This sounds obvious written down. In practice it is the harder path, since removing something usually means rebuilding what relied on it. We think that cost is worth paying. An attacker cannot exploit a weakness in a system that no longer exists.

What does a small attack surface actually look like?

Removal is the bluntest way to shrink what can be hit. The broader habit behind it has a technical name: keeping the attack surface small. Attack surface is a plain idea, the sum of every place where an attacker could try a key in a lock. Every exposed service, every third-party library, every plugin is one more lock to defend. Our definition of good security starts here: the strongest code is the code you do not run, and the safest data is the data you never stored.

Consider what a third-party library or plugin actually is. When a developer pulls one in, they are trusting a stranger, often an unpaid volunteer, to keep that code safe for as long as it runs. The library needs its own updates, its own security fixes, its own maintainer paying attention. If that maintainer loses interest, changes jobs or simply stops answering, the code keeps working, but nobody is watching it any more. A flaw found after that point stays open for good, which is the abandonment problem from the previous section arriving through a side door. Multiply this by the many components a typical application depends on, and the picture becomes clear. Every dependency is a small promise made by someone you have never met, and some of those promises quietly expire. Running fewer of them means owing your safety to fewer strangers.

The systems you sign in to, pay through, and that our apps talk to are written in Go. PHP is gone, and with it the long tail of libraries, plugins and dependencies that PHP applications tend to drag behind them.

We chose Go for our most critical systems because it answers the dependency problem at the language level. Go is memory safe: the language manages memory for the programmer, which rules out a whole class of bugs such as buffer overflows, and CISA lists Go among memory safe languages in The Case for Memory Safe Roadmaps. That class is larger than it sounds: the Chromium project finds that around 70% of its serious security bugs are memory safety problems. Go's standard library covers much of what a web service needs, including cryptography, so a Go service needs fewer third-party packages, which means fewer of those promises from strangers. The cryptography is taken seriously enough that Go's own cryptography module is validated under the US government's FIPS 140-3 standard, CMVP certificate #5247. And when a flaw does surface in the wider ecosystem, the Go security team curates a vulnerability database, and its govulncheck tool reports only the vulnerabilities in code a program actually calls, which keeps alerts low-noise and actionable.

That matters because of how widespread, and how old, PHP deployments are. W3Techs reports that PHP is used by 69.2% of all websites whose server-side language it knows, with 26.6% of PHP sites still on PHP 7 and 7.7% on PHP 5, measured on 27 October 2026. The PHP project itself supports each release branch for two years of bug and security fixes, then two more years of critical security fixes only. PHP 7 and PHP 5 are past all of that. A large share of the web runs on code its own makers no longer protect, which is the losing race from the first section entered voluntarily.

Our website is static pages built in advance, with no server-side code generating them when you visit. A page that is just a file has very little to attack. On the question of how much can be hit, this is our answer: as little as we can manage.

What data do we keep about you?

A small surface limits how an attacker could get in. The second question asks what they would find if, one day, one of them got in anyway. Our answer is to make the finding as boring as possible: less data, kept for less time.

We only ask for what is needed to run an account. Our privacy policy lists it plainly: a username, an email address, an encrypted password and the IP address used at sign-up. Payments go through third-party payment processors, so your card details live with specialists whose entire business is protecting them, not with us.

We are also tightening what happens over time. Old, unused accounts will be deleted automatically. Data that does not exist cannot leak, cannot be stolen, and cannot be demanded. An account you abandoned years ago should not sit around as a liability with your name on it. If the race is ever lost on our side of the fence, the prize on the table should be as small as we can make it.

The same logic applies beyond us, because other companies lose races too. Many of the leaks people suffer happen at shops, forums and services they signed up to long ago. That is why we offer data breach alerts: our Data Breach Scanner checks known data leaks for your email address and emails you if it shows up, so you can change passwords before the leak is abused.

What happens if something breaks anyway?

The third question has two halves: recovering, and closing the gap. Recovery first. Good security planning assumes bad days. Hardware fails, suppliers change, and sometimes the right move is simply to walk away from a piece of infrastructure.

Our systems are built so they can be recreated or moved elsewhere if needed. For you, this means that a failure, or a location that no longer meets our standards, does not have to turn into a long outage, because the affected system can be rebuilt or moved. If we ever conclude that an environment is no longer good enough, we can leave it rather than negotiate with it.

Resilience is not a dramatic quality. It mostly shows up as things continuing to work, and in this frame it is what keeps a lost round from becoming a lost season.

How fast do fixes reach our systems?

The other half of the third question is speed. None of the above removes the need to patch; it changes what patching has to carry. With a small surface and current software, applying a fix is routine rather than a project.

Our rule is simple: updates go out as soon as fixes exist. The October measurements explain why. When exploit attempts arrive within minutes and hours of a fix being published, and sometimes before one exists, a fix that sits waiting protects nobody. We treat a released patch as a starting gun. The stretch between a fix existing and a fix being applied is the one part of the race a defender fully controls, so it is the part we refuse to concede.

And because our stack is small, there is simply less to patch, which is where the three questions meet: the less there is to hit, the faster the gap closes.

Put side by side, the questions and the principles that answer them look like this:

What does all of this mean for you?

It means the three questions have answers you can feel. Less code stands between you and your account, so there are fewer places where something can go wrong. Less of your data exists, so even a worst case exposes little. And our systems can be rebuilt, so a bad day for us does not have to become a long outage for you.

We will be honest about the limit of all this. The race we started with cannot be reliably won, by us or by anyone, because flaws are sometimes exploited before anyone knows they exist, and no architecture changes that. No provider can promise zero risk, and anyone who does is selling confidence rather than security. What we can promise is the shape of a loss: few ways in, little to take, and a quick way back. We cannot guarantee we will win every round of the race. We have built so that losing one costs you as little as possible, and we think that promise, kept consistently, is worth more than a bold one that cannot be.

Security is also a shared effort. The strongest setup we can build still benefits from good habits on your side, so if you want practical steps, start with our guide on how to increase your online security. And if you are choosing a VPN, with us or anyone else, ask the provider how they think, not just what they sell. The answer tells you a lot about how your quiet weeks, and the loud ones, will go.