Anthropic's Mythos Can Find Thousands of Zero-Days. Who Fixes Them?
Today, Anthropic announced Project Glasswing. Amazon, Apple, Microsoft, Google, CrowdStrike, Nvidia, Palo Alto Networks, and others are participating. At the center of it is Mythos Preview, a frontier AI model that Anthropic won't release publicly because of how good it is at finding and exploiting software vulnerabilities.
The scale of what Mythos can do is hard to overstate. It has already identified thousands of high-severity zero-day vulnerabilities across every major operating system and web browser. It found a 27-year-old flaw in OpenBSD that survived decades of expert review. It caught a 16-year-old bug in FFmpeg, in a line of code that automated testing tools had hit five million times without flagging. It chained together multiple Linux kernel vulnerabilities to escalate from basic user access to complete machine takeover. No human guided it through any of this.
Anthropic is backing the initiative with $100 million in usage credits and $4 million for open-source security organizations. Their frontier red team lead, Logan Graham, put it directly: "If we are crossing the Rubicon where you can functionally automate those capabilities and make them very cheap as well, then we're in an entirely new world."
He's right. But the headlines today are all about what Mythos can find. Nobody is asking the harder question.
Discovery Was Never the Bottleneck
Talk to any CISO or engineering leader who has been through a pentest engagement. Ask them what the hard part was. They won't say "finding the vulnerabilities."
They'll say: getting them fixed.
The report arrives. Findings get triaged in a meeting. Engineers interpret vague remediation guidance and write patches without clear context. Fixes ship without anyone retesting the original exploit. Weeks pass. Months, sometimes. The vulnerability sits in production the whole time, marked "in progress" in a Jira ticket nobody is looking at.
Anthropic's previous public model, Opus 4.6, found about 500 zero-days in open-source software. Mythos found thousands in weeks. Now multiply the volume of findings most security teams receive by 10x. By 100x. The remediation infrastructure at most companies can barely handle what they're finding today.
Project Glasswing is going to generate an enormous number of discoveries. The question every security team should be asking right now isn't "can we find more?" It's "can we fix what we already know about?"
The Vulnerability Pipeline Is Already Overflowing
This isn't a future problem. The data from Q1 2026 is already bleak.
Georgia Tech's Vibe Security Radar tracked 35 new CVEs directly introduced by AI-generated code in March, up from six in January. The researcher running the project estimates the real number is 5 to 10x higher, because most AI coding tools don't leave detectable traces.
AppSec Santa tested 534 AI-generated code samples across six LLMs. One in four contained confirmed security vulnerabilities. Black Duck audited 947 codebases and found mean vulnerabilities per codebase jumped 107% year-over-year. Veracode analyzed 1.6 million applications and reported high-risk vulnerabilities increasing from 8.3% to 11.3% of all findings. Aikido Security's production data shows AI-generated code now causes 1 in 5 enterprise breaches.
And Stanford found that developers using AI assistants wrote less secure code while reporting higher confidence in its security. The developers who produced the least secure output rated their trust at 4 out of 5. The ones who wrote the most secure code? 1.5.
The code looks right. The scanners come back clean. The application is exploitable.
Source Code Scanning and Live Exploitation Are Different Exercises
This part matters, and it's where most teams have a blind spot.
SAST tools (Snyk, SonarQube, Semgrep) read source code and pattern-match against known vulnerability signatures. They're fast. They plug into CI/CD. They've gotten better with AI. Keep using them.
But they answer one question: does this code match a known bad pattern?
An attacker asks something else entirely: can I get into this running application?
Those are not interchangeable. Three examples of what falls through the gap:
Business logic flaws. Coinbase disclosed a vulnerability in 2022 where users could trade one cryptocurrency using the balance of a different asset. Every function in the code worked as designed. The flaw only appeared when you executed the workflow as a real user, in the real application, with real account state. Coinbase paid $250,000 to the researcher who found it. According to Imperva, 27% of API attacks now target business logic, a 59% year-over-year increase.
Prompt injection at the application layer. In February 2026, Orca Security disclosed RoguePilot: a passive prompt injection attack against GitHub Copilot in Codespaces. An attacker embedded invisible instructions inside a GitHub Issue using HTML comments. When a developer opened a Codespace from that issue, Copilot processed the hidden instructions, read privileged secret files, and exfiltrated the repository's GITHUB_TOKEN to an external server. Full repository takeover. No click required beyond opening the Codespace. Separately, CVE-2026-29783 showed that prompt injection through repository files could bypass Copilot CLI's command safety validation entirely. No source-code scanner has a detection rule for either attack.
Chained privilege escalation. Two functions that individually look clean and pass every scan. But call them in sequence as an authenticated user, and they escalate you to admin. This only shows up when you test the running application with real sessions and real state. It will never appear in a source-code review. Less than 1 in 10 SAST findings turn out to be true positives. Meanwhile, the vulnerability classes that lead to actual breaches go untested because they require running the application, not reading the code.
Mythos finding zero-days in source code is a leap forward. But confirming that a live application is actually exploitable through a specific attack chain is a different exercise entirely. Most organizations have zero coverage for the second one.
The Deploy Math Still Doesn't Work
Average engineering team: hundreds of deploys per year. Security tests: fewer than five.
Every deploy in between is an open window. AI coding tools have tripled deploy velocity at many companies over the past eighteen months. Testing infrastructure hasn't moved.
The $30K-$80K annual pentest tests a snapshot. The PDF arrives weeks later describing a codebase that has already shipped dozens of times since the engagement ended. Remediation guidance is vague. Fixes go out without retesting.
A quarterly test in a continuous-delivery world isn't a security practice. It's a checkbox.
Five Questions Worth Asking After Today's News
If Glasswing has you thinking about your own stack, run these past your security and engineering leads.
1. Does anything test the running application when you deploy, or just the source code?
"Our SAST runs on every PR" is a real answer. It's also incomplete. You're testing what the code looks like on paper. You're not testing what an attacker would find when they probe your live environment with real credentials, real session tokens, and real chained requests.
2. When you get a finding, can you confirm it's actually exploitable?
Scanner alerts are hypotheses. An exploit chain is proof. If your team triages hundreds of alerts per scan and most turn out to be noise, security loses credibility with engineering. Engineers stop reading the tickets. The backlog grows. Real issues get buried. This is how confirmed vulnerabilities sit in production for months.
3. From discovery to verified fix: how many days? Be specific.
Not "how long to open a ticket." How long until the patch is written, deployed, and retested against the original attack? At most organizations, this number is measured in weeks or months. Every one of those days, the vulnerability is live.
4. Is anyone testing for prompt injection in your deployed application?
If you're shipping any AI-powered feature, this is no longer optional. RoguePilot proved that hidden prompts in trusted content (GitHub Issues, PRs, README files) can hijack AI agents into exfiltrating secrets and running arbitrary code. Your SAST tool has no rule for this. Most pentest firms aren't testing for it yet either.
5. Could you produce continuous security testing evidence for an auditor today? Not next quarter. Today.
SOC 2, ISO 27001, PCI DSS, CMMC. These frameworks require evidence. At most companies, producing it means a weeks-long scramble through old screenshots, Jira tickets, and PDF reports from engagements that tested a version of the app that no longer exists.
What Comes Next
Project Glasswing is a big deal. For the first time, the largest technology companies are collectively acknowledging that AI's offensive security capabilities have outpaced the defensive infrastructure. Anthropic deserves credit for restricting the model's release and channeling it toward defense rather than racing to ship it.
But the asymmetry they're responding to isn't just about finding versus attacking. It's about finding versus fixing. The security industry has spent twenty years optimizing for discovery. Every year, finding gets faster and cheaper and more automated. And every year, the gap between "we found a vulnerability" and "we deployed a verified fix" stays roughly the same.
More finding, without faster fixing, just means bigger backlogs.
The organizations that come out of this era in good shape won't be the ones that found the most vulnerabilities. They'll be the ones that closed the loop: found, fixed, retested, and proved it, continuously, on every deploy. It's the reason we started BestDefense.
Anthropic just showed us that AI can find what no human team could. The question is whether your security stack can handle what it finds.