This week, Anthropic announced Project Glasswing: a coalition of AWS, Apple, Google, Microsoft, CrowdStrike, Palo Alto Networks, and others, formed around a single uncomfortable fact. Their frontier AI model, Claude Mythos Preview, can find and exploit software vulnerabilities better than all but the most skilled humans. It has already discovered thousands of high-severity zero-days across every major operating system and web browser, including bugs that survived decades of human review and millions of automated security tests.
The same day, Chris Hughes published "Vulnpocalypse" on Resilient Cyber, documenting how AI-driven discovery has reached critical scale. XBOW became HackerOne's top-ranked researcher. AISLE found all 12 OpenSSL CVEs in a coordinated release. DARPA's AI Cyber Challenge achieved autonomous vulnerability discovery at $152 per task. Nicholas Carlini's assessment: "Current models are already better vulnerability researchers than I am, and in a year, they will likely be better than everyone."
The industry response to all of this has been remarkably consistent: alarm about the volume, optimism about the technology, and almost no discussion of the part that actually breaks.
Remediation.
Discovery has gone from linear to exponential. In 2025, 48,185 CVEs were published, up 21% year over year [1]. FIRST.org projects approximately 59,000 for 2026, with realistic scenarios exceeding 100,000 [2]. Mythos-scale models will be broadly available within months. Anthropic said it plainly: "frontier AI capabilities are likely to advance substantially over just the next few months" and "it will not be long before such capabilities proliferate, potentially beyond actors who are committed to deploying them safely."
Remediation capacity, meanwhile, is flat. It takes most organizations 9 to 19 months to close half of their exposed vulnerabilities [3]. That number hasn't meaningfully improved in a decade. Teams are the same size. Patch cycles are the same length. Change management processes are the same speed. The entire remediation pipeline was designed for a world where 25,000 CVEs arrived per year in a predictable stream.
Double the input. Same throughput. The queue grows without bound.
And it gets worse. Exploitation timelines have collapsed alongside the discovery acceleration. Sergej Epp's Zero Day Clock data shows the median time from disclosure to exploitation dropped from 771 days in 2018 to 6 days in 2023 to hours in 2024 [4]. In 2026, 67% of exploited CVEs are zero-days, weaponized before public disclosure [4]. You're not just getting more findings. You're getting less time to act on each one.
The standard explanation for the remediation bottleneck is capacity: not enough people, not enough time, too many competing priorities. That's true but incomplete. The deeper problem is signal.
Consider what happens when a scanner reports 10,000 findings. Every one of those findings enters the remediation pipeline. Tickets get filed. Teams get assigned. Meetings get scheduled. Each finding consumes remediation capacity whether or not it represents real risk.
How many of those 10,000 are actually exploitable in your specific environment?
The industry data is consistent: the vast majority are not. A CVE can be present on a resource, the package can be loaded and reachable, and it's still not exploitable because the vulnerable feature isn't enabled, the required configuration isn't set, or the necessary preconditions don't hold. Scanners check presence. Some check reachability. None verify whether the specific exploitation conditions are met on that resource.
This is the signal problem. Remediation teams aren't slow because they lack skill or discipline. They're slow because they're spending 80% of their capacity on findings that were never real threats. The bottleneck isn't remediation capacity. It's the noise consuming that capacity.
When you're processing 10,000 findings and 9,000 of them aren't exploitable, you don't need a faster pipeline. You need a filter.
At 25,000 CVEs per year with 30-day exploitation windows, you could afford some waste. Triage was imperfect but the margin was forgiving. Patch everything scored High or above, eventually you'd get to most of the real risks.
At 60,000+ CVEs per year with hours-to-exploitation windows, waste is fatal. Every hour spent investigating a non-exploitable finding is an hour not spent on one that's being actively weaponized. The remediation capacity you waste on noise is the same capacity you needed for the real threats that just got exploited.
This is why faster patching alone doesn't solve the problem. You can cut your patch cycle from 30 days to 7 days and still lose, because you're patching the wrong things first. Severity-based prioritization (CVSS 9.8 first, then 9.0, then 8.5) catches everything important eventually, but "eventually" used to be weeks and is now hours.
The remediation bottleneck isn't a speed problem. It's a targeting problem.
The discovery side of vulnerability management just got an exponential upgrade. The remediation side needs one too, but not the one most people expect.
The answer isn't more people. You can't hire your way out of exponential growth. The answer isn't faster patching infrastructure. You can automate patch deployment to near-zero latency and still waste cycles on the wrong findings.
The answer is dramatically reducing the number of findings that enter the remediation pipeline in the first place. Verify exploitability before you file the ticket. Check whether the specific conditions for exploitation are met on each resource. Remove the 80-90% of findings that aren't real threats before they consume a single hour of remediation capacity.
What remains is a manageable queue of verified, actually-exploitable vulnerabilities. Now your remediation capacity goes where it matters. Now your 7-day patch cycle covers the things that are actually dangerous. Now your teams are fixing real risks instead of processing scanner noise.
This isn't a theoretical capability. Condition-level verification checks whether each exploitation condition is met on each resource, agentlessly, with a full audit trail from the intelligence source to the test plan to the verdict. The output is binary: exploitable or not, and here's exactly why.
And here's the part that gets overlooked: the conditions that make something exploitable are the same conditions you can change to make it not exploitable. A kernel CVE that requires a specific sysctl setting? Disable it. A library CVE that requires a specific API endpoint? Restrict access. A container CVE that requires a specific Linux capability? Drop it. When you know why something is exploitable, your remediation options expand from "patch the component" to "change the cheapest condition." That's often a config change that takes minutes versus a patch cycle that takes weeks.
Here's the thing everyone is missing in the Glasswing conversation. If LLMs can discover vulnerabilities at this scale, they can fix the code too. The same capability that finds the bug can generate the patch. Discovery and remediation don't have to be separate problems anymore.
But generating a fix is the easy part. Rolling it out is not. Testing, change management, deployment risk, downtime. That cost is real whether the finding was exploitable or not. An AI-generated patch for a CVE that was never exploitable on your infrastructure still requires the same rollout process as one for a CVE that's actively being weaponized. When you're looking at thousands of findings, you can't afford to roll out fixes for all of them just because the fix was cheap to write.
So the first question isn't "can AI write the patch." It's "should this be patched at all." Which findings are actually exploitable in your environment? Which ones have their exploitation conditions met on your specific resources? Answer that first. Then let AI generate and roll out fixes for the ones that actually matter.
That's the sequence that works: verify exploitability, then prioritize by real risk, then generate and deploy targeted fixes. Skip the first step and you're automating waste at scale.
Anthropic launched Glasswing because they believe the window for defenders to get ahead is narrow. They're right. But getting ahead doesn't mean finding vulnerabilities faster. Discovery is solved. Getting ahead means closing the gap between discovery and effective remediation before that gap becomes permanently unsurvivable.
The organizations that survive the next two years of AI-accelerated vulnerability discovery won't be the ones with the most scanners or the fastest patch pipelines. They'll be the ones who verified what was actually exploitable, let AI generate fixes for what mattered, and stopped wasting cycles on everything else.
The discovery revolution already happened. The remediation revolution is the one that matters now.
[1] Gamblin, J. (2026, January 1). "2025 CVE Data Review." https://jerrygamblin.com/2026/01/01/2025-cve-data-review/
[2] FIRST.org. (2026, February 11). "Vulnerability Forecast for 2026." https://www.first.org/blog/20260211-vulnerability-forecast-2026
[3] Industry average across multiple reports. Typical enterprise takes 9-19 months to remediate half of known exposed vulnerabilities.
[4] Epp, S. Zero Day Clock data, cited in Hughes, C. "Vulnpocalypse: AI, Open Source, and the Race to Remediate." Resilient Cyber, April 7, 2026. https://www.resilientcyber.io/p/vulnpocalypse-ai-open-source-and
[5] Hughes, C. (2026, April 7). "Vulnpocalypse: AI, Open Source, and the Race to Remediate." Resilient Cyber. https://www.resilientcyber.io/p/vulnpocalypse-ai-open-source-and
[6] Anthropic. (2026, April 7). "Project Glasswing." https://www.anthropic.com/glasswing