On 1 May, the NCSC published a blog post titled “Preparing for a vulnerability patch wave.” Ollie Whitehouse, the agency’s Chief Technology Officer, laid out a straightforward thesis: AI is now capable of finding software vulnerabilities at scale, and the resulting wave of disclosures will force a correction of accumulated technical debt that the industry has spent decades deferring. His recommendation was to start reducing attack surface now, before the wave arrives.
Three weeks later, Anthropic published the first update from Project Glasswing. Partners using a preview of its unreleased Claude Mythos model had collectively identified more than 10,000 high- or critical-severity vulnerabilities in systemically important open source projects — in a single month. As of 22 May, 1,596 of those had been disclosed across 281 projects. Ninety-seven had been patched. Eighty-eight had been assigned a CVE.
The wave, it turns out, is not arriving. It is already here. And by almost any measure, the defence side is not keeping pace.
What the numbers actually mean
The gap between 10,000 vulnerabilities found and 97 patched is not primarily a disclosure problem or a researcher problem. It is a remediation problem. Finding bugs with AI is now tractable at scale in a way that patching, testing, and deploying fixes is not.
Patches require human review to verify the finding is real, human engineering time to write and test a fix, coordination with maintainers, distribution through package registries, and then adoption by downstream consumers. Each of those steps is bounded by human throughput, and collectively they impose a ceiling on how fast the industry can absorb security improvements — regardless of how fast they are discovered.
This is the structural shift the NCSC was pointing at. The bottleneck has moved from the supply of vulnerability intelligence to the capacity to act on it. Organisations that have been managing that bottleneck comfortably — because intelligence was slow — are about to discover they cannot maintain the same posture when the supply rate changes by an order of magnitude.
Why this is not just an open source problem
The Glasswing programme focused on open source for the obvious reason that source code is accessible. But the same AI capability applies to any codebase, including commercial software, proprietary enterprise applications, and the firmware that runs in critical infrastructure.
The difference is that open source at least has a pathway: a maintainer, a CVE, a patch. Proprietary software and embedded systems often lack all three. The industrial control systems running in water treatment, energy distribution, and manufacturing were not written with the assumption that researchers would be finding vulnerabilities faster than vendors could ship patches. Many are not patchable at all in any operationally convenient timeframe.
This is where the NCSC’s framing of a “forced correction of technical debt” becomes specifically troubling for CNI operators. The technical debt in question is not just legacy code. It is the entire accumulated assumption that the attack surface could be managed through selective patching of high-priority CVEs. That assumption depended on the vulnerability pipeline flowing at a speed humans could manage. That assumption is being revised.
The exploitation side of the equation
Mandiant’s M-Trends 2026 report puts a sharper edge on the problem: 28.3% of CVEs are now exploited within 24 hours of disclosure. That figure was under 10% five years ago. The acceleration on the exploitation side reflects the same dynamic — AI-assisted exploit development, shared proof-of-concept repositories, and an increasingly professional criminal infrastructure that monetises vulnerability intelligence rapidly.
This creates a structural disadvantage for defenders that is independent of any specific CVE. If the distribution of time-to-exploit is compressing toward zero while the distribution of time-to-patch remains measured in days-to-weeks for most organisations, the window in which a patch can meaningfully reduce risk before exploitation is shrinking. For some vulnerabilities, particularly those in widely deployed internet-facing software, the patch window may now effectively be zero.
The practical implication is that patching, while still necessary, is increasingly insufficient as a primary risk control. Organisations that treat vulnerability management as a process of deploying patches within SLA will find those SLAs increasingly unachievable for a growing proportion of CVEs.
What this changes for risk management
The NCSC’s recommendations in the May advisory were deliberately practical: reduce internet-facing attack surface, enable automatic updating where possible (including for embedded and IoT devices), and begin transitioning away from end-of-life systems that cannot be patched to vendor support.
These are reasonable starting points, but they frame the response as a project to be completed. The more accurate framing is that the vulnerability landscape has structurally changed, which means risk management practices need to change permanently.
A few adjustments are worth prioritising. First, compensating controls need to carry more weight. Network segmentation, least-privilege access, and anomaly detection are not alternatives to patching — they are the risk reduction that happens in the window before patching is possible. As that window expands for some vulnerabilities, their relative importance increases.
Second, third-party and supply chain risk assessments need to account for the new discovery rate. If your software suppliers’ patching SLAs were calibrated against historical disclosure volumes, those SLAs are now outdated. The question to ask vendors is not what their patch SLA is, but how they are managing a sustained increase in disclosure volume — which is what Glasswing and similar programmes will produce.
Third, legacy systems that cannot be patched need to be treated with a different risk calculus than they were twelve months ago. Boards and executives who have been tolerating a known risk because historical exploitation rates were low should expect that calculus to change as AI lowers the cost of both finding and exploiting vulnerabilities in those systems.
The opportunity the NCSC is not quite saying aloud
Buried in the framing of Project Glasswing is a point worth stating explicitly: AI is finding vulnerabilities that have existed for years or decades and remained undiscovered by human researchers. The nginx heap overflow in CVE-2026-42945, disclosed in May, had been present in every nginx build since 2008 — eighteen years. If AI had been applied to that codebase in 2015, the vulnerability would have been found in 2015. It was not, because the capability did not exist.
This means the current stock of undiscovered vulnerabilities in critical codebases is larger than previously assumed, and is now being drawn down at a pace that will not slow. The NCSC is right that this represents a “forced correction.” The correction is not a one-time event. It is a sustained increase in the rate at which known vulnerabilities need to be managed.
Organisations that adapt their risk posture now — increasing compensating controls, reducing legacy exposure, and revising vendor expectations — will be in a materially better position than those that wait for the correction to arrive on their systems.
The wave has broken. The question now is how well prepared the shore is.