What happens when AI finds more vulnerabilities than we can fix?

AI is changing the economics of vulnerability discovery. But who has the capacity, resources, and responsibility to fix what it finds?

Earlier this year the UK National Cyber Security Centre (NCSC) raised the flag and warned us, rightly so, of the approaching vulnerability patch wave, when AI starts to expose many years of collective technical debt and the associated security weaknesses in the software we depend on.

Here we are five months later and two critical vulnerabilities in PHP, the tech underpinning much of the internet’s websites have been found. These weaknesses have been hidden for a very long time, and organisations running these impacted systems are racing to remediate, some taking services offline as a preventative measure.

Two today, and more to follow for sure. What happens when our ability to discover vulnerabilities starts to overtake our ability to fix them?

The economics of discovery

The changing economics are not just confined to vulnerability research. Cyber security researchers at Straiker discovered a CyberCartel hacking group using a network of AI agents to coordinate attacks against financial institutions across Latin America.

They choose not to rely on one single frontier model, instead we’re told they combined the use of Claude, Grok and Kimi. Assigning different tasks to different agents (via a harness to route) and redirected activity when models refused to cooperate.

I wrote recently about AI agents communicating with each other; I’d like to see this communication channel. These attackers have assembled commercially available AI capabilities into and automated offensive operation. No access to Mythos (and others) required!

Who finds, who fixes, and who pays?

AI is democratising vulnerability discovery, without democratising the ability to remediate what it finds. What if the software supporting your commercial applications and services depends on an open-source ecosystems, sometimes with limited funds and resources.

Sometimes organisations may not directly manage the vulnerable software on which their services depend. They’re hidden in the supply chain, embedded in a commercial application, network appliance, or managed service.

Security teams can identify the vulnerability but may have to lean on their procurement teams to refer to contractual obligations, with unpredictable assurance issues and remediation timelines.

For years we’ve invested in understanding our technical debt and dependencies through asset management and software bills of materials. But just because we know where it is, doesn’t mean we can fix it.

As AI accelerates the discovery of serious weaknesses across lots of deployed tech, the majority of organisations are likely to be dependent on the same relatively small group of suppliers for operational resilience.

When the patch becomes the intelligence

A security patch does more than fix a vulnerability. It reveals where the weakness existed and through analysis of the changes provides useful intelligence about how the exploited systems that remain unpatched.

This is not new news, as attackers have long reverse engineered security updates to develop exploits against vulnerable systems. What’s different now is the speed at which this process can happen.

The CyberCartel findings show us how attackers are already experimenting with orchestrated AI capabilities. Although that operation is not linked to the PHP vulnerabilities, it does show how different models can be combined to automate parts of an offensive campaign.

For defenders, that’s not the case. It could take a supplier weeks to develop and validate a patch. Then when it’s released it still needs to be aligned to an affected system, tested for compatibility, and deployed without disrupting operations.

Traditional disclosure and remediation processes depend on giving defenders a reasonable time to respond. AI will compress that opportunity, especially where vulnerabilities affect widely deployed software.

When patching becomes the risk

The NCSC advice for the PHP vulnerabilities includes taking your impacted system offline, where fixing cannot be achieved immediately. From a security perspective, this may be necessary, and we’ve had a few high-profile organisations take their site offline.

If only it was that easy for everyone. There are plenty of critical service providers that just can’t simply go dark.

Our national cyber resilience will be tested when we have a critical vulnerability that gets reported, in a responsible way (not leaked early as in this case), which demands fixing simultaneously right across our banks, hospitals, government, and through their supply chains.

Finding the next thousand

AI-enabled vulnerability discovery isn’t inherently a problem, but finding the weaknesses before adversaries exploit them is a real defensive advantage. I’m not saying that faster scanning will make your team patch quicker. If only.

This brings back the question of software resilience, and the software foundations we all depend on, including supporting our national infrastructure.

These PHP vulnerabilities, originally thought to be too complicated to exploit, will eventually be patched. For a moment some of us will take a breath. 30 million websites we know about, but as for what remains buried and hidden in the architecture, some of us will hold our breath.

We’re at a point where the biggest constraint on cyber security professionals isn’t just our ability to discover vulnerabilities with AI tools, but our capacity to deal with what we find. What’s exposed, what’s critical to your services, and what can be safely taken off line while we remediate.

Finding the next thousand vulnerabilities may just be the easy part.