On 1 May, NCSC CTO Ollie Whitehouse published a blog post warning that AI-accelerated vulnerability discovery would force a reckoning with accumulated technical debt. His advice: start reducing attack surface before the wave arrives.
Three weeks later, Anthropic published the first update from Project Glasswing. Partners using a preview of the unreleased Claude Mythos model had found 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 disclosed across 281 projects. Ninety-seven patched. Eighty-eight with CVEs assigned.
The wave didn’t wait for people to get ready.
10,000 found. 97 patched. The gap is the problem.
That ratio is not a disclosure problem. It’s not a researcher pipeline problem. It’s a remediation problem, and it’s structural.
Finding bugs with AI is now tractable at scale. Fixing them is not. Patches require human review to confirm the finding is real, engineering time to write and test a fix, coordination with maintainers, distribution through registries, and then adoption downstream. Every step is bounded by human throughput. Collectively, they impose a ceiling on how fast the industry can absorb security improvements, a ceiling that doesn’t move just because the discovery rate has gone up by an order of magnitude.
This is the shift the NCSC was pointing at. The bottleneck has moved. It’s no longer the supply of vulnerability intelligence; it’s the capacity to act on it. Organisations that have been managing their patch queues comfortably (because the queue moved at a pace humans could handle) are about to discover that assumption no longer holds.
This isn’t an open source problem with a side of critical infrastructure
Glasswing focused on open source for the obvious reason: source code is accessible. But the same AI capability applies to any codebase. Commercial software, proprietary enterprise applications, the firmware running inside water treatment systems and energy distribution infrastructure: all of it can be analysed.
The difference is that open source has a pathway. There’s a maintainer, a CVE process, a patch mechanism. Proprietary embedded systems often lack all three. The industrial control systems running CNI were written under the assumption that finding bugs would be slow. Many can’t be patched in any operationally convenient timeframe even if a bug is found. “Patch the PLC” is not a real-time option in a live generation facility.
The NCSC’s phrase, “forced correction of technical debt,” understates what this means for CNI operators. The debt isn’t just legacy code. It’s the entire operating assumption that selective patching of high-priority CVEs is sufficient risk management. That assumption depended on the vulnerability pipeline flowing at human speed. That assumption is done.
The exploitation side is accelerating in parallel
Mandiant’s M-Trends 2026 report: 28.3% of CVEs are now exploited within 24 hours of disclosure. Five years ago, that figure was under 10%. The same AI-assisted development dynamic that’s accelerating discovery is accelerating exploit development: proof-of-concept repositories, shared tooling, an increasingly professional criminal infrastructure that turns vulnerability intelligence into operational capability fast.
If time-to-exploit is compressing toward zero while time-to-patch stays measured in days-to-weeks for most organisations, the window in which patching can meaningfully reduce risk is shrinking. For some widely deployed internet-facing software, that window may now be effectively zero.
Patching is still necessary. It’s just increasingly insufficient as a primary risk control. Organisations treating vulnerability management as a patch-within-SLA process will find those SLAs unachievable for a growing proportion of CVEs. The SLA model was calibrated for a different disclosure environment.
What actually needs to change
The NCSC’s practical recommendations (reduce internet-facing attack surface, enable automatic updating where possible, start transitioning away from end-of-life systems) are sound. They’re also framed as a project with a completion point. The more accurate framing is that the landscape has changed permanently.
Compensating controls now carry more weight than they used to. Network segmentation, least-privilege access, and anomaly detection aren’t alternatives to patching; they’re the risk reduction that happens in the window before patching is possible. As that window grows for certain vulnerability classes, the relative value of compensating controls increases proportionately.
Vendor patching SLAs need renegotiating. If your suppliers’ SLAs were calibrated against historical disclosure volumes, they’re outdated. The right question for vendors is no longer “what’s your patch SLA” but “how are you managing a sustained increase in disclosure volume that isn’t going back down.”
Legacy systems need a different risk calculus. Boards that have been tolerating known-vulnerable systems because historical exploitation rates were low should reconsider. AI doesn’t just accelerate finding new bugs. It accelerates finding old ones too.
The thing the NCSC didn’t quite say
Project Glasswing is surfacing vulnerabilities that have existed for years, undiscovered. The nginx heap overflow in CVE-2026-42945 had been present in every nginx build since 2008. Eighteen years. If this AI capability had existed in 2015, that vulnerability would have been found in 2015.
The implication: the stock of undiscovered vulnerabilities in critical codebases is larger than anyone assumed, and it’s now being drawn down at a rate that won’t slow. The “forced correction” is not a one-time event. It’s a new baseline.
Organisations adjusting their risk posture now, with more compensating controls, reduced legacy exposure, and revised vendor expectations, will be in a materially better position when Glasswing Phase 2 drops another ten thousand. The wave has broken. What matters now is what was already built on the shore.