6,202 high or critical severity vulnerabilities discovered. 97 patched.
Read that again. Ninety-seven. Out of more than six thousand.
Anthropic's Claude Mythos Preview has been scanning open-source software for about four months. In that time it has flagged over 23,000 issues across more than 1,000 projects, and independent security firms validated over 90% of the high-severity findings as real. The discovery side is cranking at machine speed. Thousands of critical bugs per month, at a cost of tens or hundreds of dollars per vulnerability.
The fix side? Volunteer maintainers reviewing reports. Developers writing patches. QA teams testing for regressions. Release managers coordinating updates. Downstream distributors packaging and shipping. End users deploying and validating. Every single step is manual, resource-constrained, and slow.
The offense-defense balance just broke.
This Isn't About One AI Model
It would be easier to process this if it were limited to one research program at one company. It isn't. The capability to discover and exploit vulnerabilities autonomously is becoming a commodity. Researchers at AISLE have already shown that smaller, cheaper open-source models with the right scaffolding can detect the same classes of vulnerabilities that frontier models find. The cost floor for automated vulnerability discovery is heading toward zero.
The cost floor for fixing vulnerabilities hasn't moved. Writing a correct patch still requires a human who understands the codebase. Testing that the fix doesn't break something else still requires expertise and time. Coordinating across vendors, distributors, and customers to get the fix deployed still takes days, weeks, or months.
Mythos Preview built a working 20-gadget ROP chain exploit against FreeBSD's NFS server autonomously. In hours. That vulnerability had been sitting in the code for 17 years, granting unauthenticated remote root. The exploit exists. The FreeBSD team still hasn't shipped the fix to all affected systems.
Hours to exploit. Weeks to fix. And this is with a model restricted to a dozen trusted organizations. What happens when the next frontier model can do the same thing without access restrictions?
You Can't Patch What Doesn't Have a Patch
The traditional vulnerability management model runs on a simple assumption: find it, patch it, verify it. That model was already cracking under the weight of Microsoft's 1,129 patches in 2025, with the first five months of 2026 running even higher. Most organizations were already behind on their backlog before AI entered the picture.
Now layer on thousands of AI-discovered vulnerabilities in Linux, FreeBSD, OpenSSL, FFmpeg, curl, web frameworks, cryptography libraries, and every other open-source component your environment depends on. The patch volume is about to jump by an order of magnitude. And the bottleneck isn't your patch management tool. The bottleneck is the upstream maintainers who haven't written the fixes yet.
98.4% of what AI has found doesn't have a patch. Patching is still essential, but if it's your only strategy, you have a 98.4% gap in your security posture. Right now. Today.
The Network Layer Is Your Only Remaining Control
Every one of the most severe AI-discovered vulnerabilities requires network access to exploit. The FreeBSD NFS RCE. The OpenBSD TCP SACK crash. The FFmpeg codec flaw. If the attacker can't reach the vulnerable service, the vulnerability doesn't matter. When patches don't exist, the network layer becomes your primary defense.
Start by assuming every network service you run has an undiscovered RCE. That sounds paranoid. It's not. AI found critical vulnerabilities in software that was manually audited for decades. OpenBSD's TCP stack had a 27-year-old bug. OpenBSD. The operating system that exists specifically to be secure. Whatever you're running has bugs too.
Segment accordingly. The NFS vulnerability grants unauthenticated root over the network, but that only matters if the NFS server is reachable from untrusted networks. Internal services should be segmented from each other, not just from the internet. And every unnecessary service, every unnecessary port, every "we might need that someday" listener is an attack surface that AI will eventually find a bug in. Kill what you don't need.
Virtual patching at the network layer (WAF rules, IPS/IDS signatures, proxy-layer mitigations) can be deployed in hours when a new CVE drops. That buys time while the upstream maintainer writes the actual fix. It's not a solution. It's a tourniquet. But when you're bleeding from 6,000 wounds, tourniquets matter.
If your architecture still relies on a trusted internal network perimeter, if "it's behind the firewall" is your justification for not hardening internal services, you're operating on time you don't have.
Prioritization Gets Harder, Not Easier
When everything is critical, nothing is. CVSS scores alone don't cut it when the volume exceeds your capacity to patch.
What matters now is reachability. Can an attacker actually reach the service? A CVSS 9.8 on an air-gapped system is less urgent than a 7.5 on something internet-facing. Exploit availability matters too. The old buffer between "CVE published" and "exploit available" is gone. Mythos built working exploits for over half of a set of 100 Linux kernel CVEs in days.
Product applicability is the one most organizations get wrong. Does this vulnerability affect software actually installed in your environment? Sounds obvious. But most shops can't answer that question at scale. They don't have real-time, accurate inventory of what's running where. Without that, every CVE looks potentially relevant and prioritization turns into guesswork.
The Maintainer Problem Nobody Wants to Talk About
A huge portion of the software running critical infrastructure is maintained by volunteers. Unpaid individuals. Spare time. Weekends. These people are now getting flooded with AI-generated vulnerability reports for bugs that have been in their code for a decade or more.
Anthropic has committed $100 million in usage credits and $4 million to open-source security organizations, which helps, but it doesn't fix the structural problem. Writing a correct patch for a subtle memory safety issue in a 20-year-old codebase takes deep expertise in that specific codebase. AI can find the bug. It might even suggest a fix. But validating that the fix is correct, doesn't introduce new problems, and handles every edge case still requires a human who knows the code. There aren't enough of those humans.
If your organization depends on open-source components (it does), you need to start factoring maintainer capacity into your risk assessment. A critical vulnerability in a well-funded project with active maintainers will get patched faster than the same bug in a project maintained by one person. Your patch timeline depends entirely on their patch timeline. And you have zero control over it.
What Comes Next
The first wave of coordinated Project Glasswing CVE disclosures from partner organizations begins in July 2026. Microsoft already shipped fixes for 16 Windows vulnerabilities discovered through the program in May. There are thousands more in the pipeline.
The discovery capability will only get cheaper and more accessible. Today it's Mythos behind a restricted access program. Give it a year. Maybe less. The window where only the responsible actors have this capability is narrow, and it's closing fast.
Patch what you can. Segment what you can't patch. Monitor what you can't segment. Detect what you can't prevent. And accept that doing all of it still might not be enough, because the pace of vulnerability discovery just permanently outran our collective ability to respond.
These are scary times. Build accordingly.