We Can’t Patch All the Bugs
The people building the models are now saying out loud that patching can’t keep up.
Start with Sam Altman. Speaking to students at Stanford’s Graduate School of Business, OpenAI’s chief executive said, “I no longer think we’re going to be able to just patch all the bugs.” Defense, he said, will have to switch to a new kind of shield built with the same AI. He added that he’s somewhat astonished how little attention the problem is getting, even as the models keep improving.
The breach data points the same way. Verizon’s 2026 Data Breach Investigations Report found that exploiting a vulnerability is now the most common way attackers get in, at 31 percent of breaches. That’s ahead of stolen credentials and phishing for the first time. Over the same period, the share of known-exploited flaws that organizations fully fixed fell from 38 percent to 26 percent. That’s roughly three in four still not fully fixed. And the median time to fully fix one stretched from 32 days to 43. Exploitation went up. Complete patching went down.
PHP2Shell shows what that looks like on the ground. CISA added both flaws to its catalog of known exploited vulnerabilities on October 26. The Shadowserver Foundation counted 263,000 instances in the U.S. alone running versions of PHP that have reached end of life, where the project itself no longer ships fixes. Those servers didn’t lose the race. They were never in it.
The attackers are getting faster too. Microsoft says a China-aligned group it tracks as Storm-0940 used ARTEX, an open-source framework that runs a team of AI agents through an attack, in the supply chain attack on ConnectWise’s Cloud Backup service. In multiple cases the group went from first targeting to privileged access in under three hours. Against ConnectWise, Microsoft counted 2,900 sign-in attempts a minute.
In plain terms, the flaws are arriving faster, the attackers move at machine speed, and the fixes are reaching a smaller share of the systems that need them.
And the race starts at the moment most people think of as the finish line.
Every Fix Starts the Race
Underneath all of this is one shift: a patch is now a set of instructions for the attacker.
Start with how a fix gets out. Paul Krugman, writing on his Substack, puts it in an economist’s terms. An organization that learns of a threat can install the patch that blocks it. But the act of sending that patch out tells attackers exactly where to go after everyone who didn’t install it right away. He cites Reuters reporting from the PHP2Shell rollout: once the fix was public, AI tools could reverse-engineer the bug from it with little effort. Costin Raiu, co-founder of the incident response firm TLP:Black, called it a “race to exploit.”
That changes what a patch is. It used to be the end of the problem. Now it’s the starting gun, and it fires for the defender and the attacker at the same moment. The attacker isn’t limited by human time anymore, either. As Ben Thompson puts it, AI can substitute iteration for cleverness.
So who wins? Thompson answers with his own site. Stratechery runs on WordPress, managed by Pressable, an Automattic company. He writes that his site was patched before the vulnerability was even disclosed, and that it would be crazy for anyone to do it any other way. The platforms that get the fix early aren’t in the race at all. Anyone running their own public server is in it, against a machine reading the same release.
His conclusion is blunt. Standing up your own site or app on the open internet was already a dodgy proposition. In the age of AI, he calls it madness.
Strip away the headlines and the mechanism is simple. The moment a fix is published is now the most dangerous moment in a flaw’s life, and the only safe place to be is somewhere the fix has already landed.
For an MSP, that turns the question around. It isn’t how fast you can patch. It’s how many of your clients’ systems are still out in the open when the next release drops.
There are two ways to answer it.
Run Faster or Leave the Race
The answer arriving in MSP consoles is to run that race faster.
Start with N-able. It added AI-assisted vulnerability scanning and patching to its N-central and N-sight platforms, covering more than 900 applications, with AI-built prioritization and reports on patches that fail. Brendan Griffin, its director of threat research, told Channel Dive the objective is “to shorten the length of the exposure.” On an August earnings call, chief executive John Pagliuca said each technician today aims to manage about 300 endpoints, and AI should push that ratio much higher. That’s a real gain in speed. It’s also the same race, run with more endpoints per technician. And the patching platform is itself a target. N-able disclosed in July that attackers had exploited a previously unknown flaw in N-central.
The other answer is to leave the race. Krugman, drawing on Azeem Azhar, expects the internet to move toward partially closed domains. He compares them to gated communities, like the one his parents lived in. Outsiders could still visit, but only if someone had left their name at the gate. It worked. It was also slower and more annoying than open streets. Security, he says, will come at a cost, and the cost lands hardest on an economy built to run in the open. Ben Thompson, for his part, expects it to get worse before it gets better, and then better, because the defenders have AI too.
For a small business, that comes down to a short list of servers: the marketing site, the client portal, the old line-of-business app someone exposed so remote staff could reach it.
So here’s the choice. Take every client system that sits on the open internet. Either move it to a platform that receives fixes before they’re public, or take it off the open internet and put it behind a gate, reachable only by known users and devices. Stop running exposed servers yourself, and accept the friction that comes with it. Or keep running them, and bet that your patch tooling beats an AI reading the same release.
And there’s a fair case that all of this is overblown.
The fair objection is that PHP2Shell wasn’t the apocalypse it was billed as. Arctic Wolf’s Justin Moore told Cybersecurity Dive the reality has been less dramatic than the headlines. That isn’t a rebuttal, it’s the point, because slower exploitation only bought time for servers someone was already fixing. And a faster patch rate won’t set you apart, since everyone on the same platform gets the same automation. What separates you is showing a client how many of its systems are still on the open internet, and proving that count falls every quarter.
What to Consider
- Count what’s exposed, client by client. Pull an outside view of each client: every hostname and address reachable from the internet. Tag each one as on a platform that patches early, behind a gate, or self-run in the open. The third count is your number, and it belongs in every quarterly review.
- Ask the platform the disclosure question. Before moving a client’s site or portal, ask the host or vendor whether it receives fixes before they’re public, and get the answer in writing. A statement that sites are “protected” can mean a firewall rule rather than a patched build, so ask which.
- Gate the rest, starting with remote access. Some systems have to stay reachable without being public, like remote desktop, admin panels and the line-of-business app. Put them behind access that admits only known users and devices, and agree with the client in advance on the extra sign-ins that brings. The faster patch tool is the backstop for these, not the plan.
If this trend continues: By the end of 2027, a client’s real exposure will be how many of its systems an attacker can reach on the day a fix is published, and MSPs still reporting patch compliance will be measuring the wrong number.