Between the 20th and 27th of October 2026, there were three security news headlines which appeared within a week of each other and I couldn’t help but notice a similar thread which stitched them together.
Railway the hosting platform a lot of startups are using to run their applications, spent a few days fighting off an attacker who worked through its build systems and walked off with encrypted customer secrets, some of which the attacker went on to decrypt.
The UK’s National Cyber Security Centre warned that every version of PHP, the language behind a huge chunk of the web (through Wordpress powered websites), carried a flaw that could let an attacker run commands on a server without ever logging in. And Anthropic published research showing one of its unreleased models finding serious vulnerabilities in Google Chrome, Safari, Android, Windows and Linux, then chaining them into working attacks with very little human help. Any one of these would have been a big story, but together they say something pretty damning for the way most people and organisations are building software.
Let’s start with the Anthropic research, because it does change the economics behind the other two headlines. The finding that really stood out to me was the bug in the Linux kernel’s networking code. Against a server running a multipath TCP listener, the model’s exploit went from no access at all to a root shell, with nobody clicking anything, in a little under an hour. The flaw itself, which is now tracked as CVE-2026-98432 and rated 9.8 out of 10 in terms of severity, resides in the ordinary IPv4 TCP code that dates back to Linux 4.4, so simply switching off multipath TCP doesn’t close it. Work like this used to be owned by a handful of specialist teams with years of experience and serious budgets.
Anthropic’s point is that models can do most of this work with very little human involvement, and while this particular model isn’t public, it’s clear which way things are heading. I wrote previously about the The Cheap Attack Economy and how AI makes attacks cheap to build and cheap to repeat. This is that same shift but reaching to much lower levels of the stack, which are the parts most of us assume are someone else’s problem.
The PHP advisory shows what that means for the people defending systems. The flaw itself is a subtle pair of unrelated bugs in how PHP cleans up after a HTTP request when it runs out of memory, which can leave a worker using memory it has already handed back (real bad). The NCSC’s advice is to patch PHP, and if you can’t patch, to take the system offline. That works when the system is yours, but PHP is so widely used, that much of it sits inside the things you depend on but don’t run, like a suppliers appliance, the admin panel that shipped with a product, or a hosted service your team signed up to years ago. The Dutch NCSC is keeping a list of affected products because few organisations can say for certain what’s inside the things they’ve bought. You can’t patch those, and switching them off means switching off part of your business, so the best you can do is fence them off from the internet, chase the supplier and wait on thier timetable. Each one is a moving part in your system that only someone else can move.
Railway’s report was the one that really shocked me because they did almost everything right and still had a very bad couple of days. Their monitoring picked up the attack from a latency alert. Their customer environment variables, where applications keep things like database credentials and API keys, were stored in an encrypted format. Even so, the attacker escalated their privileges inside the build infrastructure, and kept finding new routes in as the team was closing old ones, and eventually obtained the credentials for the CI environment that let them decrypt a subset of those secrets. Railway says at most 1.85% of workspaces, around 100,000 were potentially affected, and that the attacker seemed to be hunting for AI provider API keys in particular. When the team rebuilt their internal systems afterwards, they built them with a minimal number of dependencies. I don’t think that’s a coincidence, starting again from a known good state is the moment you discover how much baggage you were carrying which increased your exposure.
If you put these stories side-by-side the lesson is less to do with any single bug and more to do with the attack surface. Every package, service, agent, sidecar and operating system you run is one more thing that can go wrong and one more thing to patch when the next advisory is published. Today, an attacker with a capable model only needs one of them to be out-of-date and you’ve got a potential breach. You need every one them to be current, and before that you need to know which of them actually exist. The NCSC has already begun talking about preparing for a wave of patches, and I think that’s the right mindset. Expect a steady stream of urgent fixes, and assume the teams who cope best will be the ones with the least to patch and the shortest distance between a fix being published and that fix running in production.
If you put these stories side-by-side the same theme is visible throughout all of them. Most teams and organisations run a vast web of packages, services, sidecars, operating systems and more recently agents. Together these form an enormous attack surface, and that’s only the part they know about. Each of those components brings its own chain of dependencies, which brings theirs and so on. My answer is to have less of it, the fewer things you have to patch and manage, the faster you can react when an advisory lands and that speed puts you in a far stronger position than an organisation with a practically infinite garden to maintain. An attacker with a capable model only needs on of those things to be out of date, and I’d much rather be the team that can find it and fix it in hours than the one still working out where to start.
The Linux bug shows how long that distance can be, even for the people whose job it is to close it. The upstream fix landed in October, but Red Hat (a famous Linux distro for enterprise) didn’t ship patched kernels until November 1st, having first rated the flaw as moderate. On November 2nd, Ubuntu’s (another famous distor) fixes were still sitting in an opt-in testing channel, with older releases yet to follow, and every one of those kernels needs a reboot before it protects anyone. Multiply that by every server, base image and appliance in an organisation and you start to see the size of the problem.
This is where edge computing earns its place. On platforms such as Cloudflare Workers, your code runs inside a lightweight sandbox called an isolate, on machines the provider runs, and there’s no operating system for you to own. You aren’t responsible for a Linux kernel, an SSH server, a package manager or a base image slowly going stale in a registry somewhere. That kernel bug from Anthropic’s research is the provider’s job to fix once across their fleet, rather than yours to fix on every server you’ve ever launched. For a lot web workloads, APIs, form handlers, login flows and content sites, the kernel isn’t something you’d consider but it’s an overhead you inherit because that’s how most servers work.
To be clear, Cloudflare Workers aren’t a silver bullet. Anthropic’s research also found bugs in V8, the JavaScript engine which powers Chrome, which is the same engine that powers isolate platforms like Cloudflare Workers. Google assigned 62 CVEs to the Chrome findings, including a heap corruption in V8 and an escape from V8’s own sandbox. Although edge computing doesn’t make the attack surface disappear, it does change how much of that surface you own and how quickly it gets fixed. With a traditional setup, a kernel or runtime flaw means every one of your servers needs patching, testing and rebooting, often by teams with other things on their plate. On an edge platform there’s one engine, maintained by a provider whose whole business depends on patching it quickly, and when they ship the fix it reaches every customer without anyone on your side doing a thing. You’re swapping a large attack surface you look after yourself for a much smaller one looked after by specialists. For most teams that’s a very good deal, as long as you go in knowing it’s a deal and not a guarantee.
The same thinking applies to the code you produce. Every dependency you pull in is a small act of trust on a team (sometimes a single person) you’ve never met, and another line on the inventory you’ll need when the next advisory arrives. I lean towards languages and frameworks with strong standard libraries for exactly this reason, because the fewer third-party packages sitting between your code and the platform, the shorter the list you’ll be checking at 2am. Just as important is the path from a fix to production. If shipping a one-line dependency bump means a two-week release train and a change board, you’ve alread lost the race against someone whose model found the bug last week. Pick a dependency, pretend it has a critical flaw, and time how long it takes our team to get a patched build live, because that number says more about your security than most audits do.
Fewer moving parts reduces how often things go wrong, and encryption decides how much it costs you when they do. Encryption in transit, meaning TLS on every connection, including the ones between your own internal services, stops someone with a foothold on your network from reading traffic as it passes through. Encryption at rest means a stolen database dump or disk is a pile of noise rather than a list of your customers. Railway’s incident is a useful reminder that encryption at rest is only as strong as the distance between the data and its keys. Their secrets were encrypted, and the attacker still read some of them because once they were deep enough inside, the credentials needed to decrypt them were within reach. Keep keys in a separate system with its own access controls, and give each service only the keys it genuinely needs. Be especially careful with the systems that build and deploy your code, because if your pipeline can quietly read everything it ships, compromising the pipeline gets an attacker everything.
None of this is new advice, security people have been telling us to reduce our attack surface for as long as I’ve been writing software. What’s new is the price of ignoring them. When a new model can build an exploit that takes a server from untouched to root in under an hour, the gap between a vulnerability existing and someone using it shrinks towards nothing, and the only real answer is to have less that can be found and fix what is found faster than it can be used. So this week, try counting. List everything that sits between a HTTP request arriving and your data at rest, every runtime, package, agent, service, proxy and credential. Then for each one, ask does it really need to be there?
The systems that will stand up against what’s coming next are the ones with the fewest moving parts.