What Happened
Between late 2024 and early 2025, Anthropic's Claude Mythos Preview AI system identified 1,596 verified vulnerabilities in open-source projects through OSS-Fuzz over a nine-week period. The discovery rate averaged about 177 vulnerabilities per week. Nine weeks after the initial snapshot, 95% of these vulnerabilities still had no public advisory, and the ratio of discovery to repair stood at approximately 16.5 to one. This was a stress test of the entire vulnerability management ecosystem, and the ecosystem failed.
Timeline
Week 0: AI system begins automated fuzzing and vulnerability discovery across open-source projects.
Weeks 1-9: 1,596 verified vulnerabilities reported to maintainers through standard disclosure channels.
Week 9 (snapshot date):
- 1,596 verified vulnerabilities on record.
- Approximately 97 patches deployed (16.5:1 discovery-to-repair ratio).
- 95% of disclosures still have no public advisory.
- Unknown number of vulnerabilities remain unpatched in production deployments.
Post-snapshot: Backlog continues to grow as AI discovery outpaces human remediation capacity.
Which Controls Failed or Were Missing
Vulnerability Response Time Controls
The standard vulnerability disclosure process assumes human-scale discovery rates. When AI accelerates discovery significantly, the response pipeline becomes a bottleneck. Your team may struggle to review, validate, patch, test, and release fixes fast enough to keep pace with incoming reports.
Your vulnerability management program likely has an SLA: critical findings patched within 15 days, high within 30, medium within 90. These timelines assume a manageable volume. At 177 new vulnerabilities per week, even a well-staffed team would fall behind.
Risk-Based Prioritization Framework
Most teams lack a systematic decision framework for choosing which vulnerabilities to patch first when resources are constrained. Without criteria for evaluating risk, exposure, and existing controls, teams may default to either patching everything (impossible at this scale) or patching nothing (unacceptable risk).
The missing control: a documented process for triaging vulnerabilities based on exploitability, exposure to untrusted input, presence of other security layers, and business criticality of the affected component.
Dependency Visibility and Inventory
If 95% of these vulnerabilities had no public advisory nine weeks after disclosure, how many enterprises even knew they were running affected code? The failure here is fundamental: you can't patch what you can't see.
Most organizations lack complete visibility into their dependency trees. You know you're using library X version 2.3, but you don't know that X depends on Y, which depends on Z, which just had a vulnerability disclosed to its maintainer but not yet published in the National Vulnerability Database.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.3
"Security vulnerabilities are identified using industry-recognized sources for security vulnerability information, and are managed by assigning a risk ranking to vulnerabilities that includes identification of all 'high-risk' and 'critical' vulnerabilities."
The standard requires you to identify vulnerabilities and assign risk rankings. It doesn't specify a response timeline for every vulnerability—it requires you to make risk-based decisions. When discovery outpaces remediation, your risk ranking process must account for likelihood of exploit, exposure, and compensating controls, not just severity scores.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation)
"The organization identifies, reports, and corrects system flaws... installs security-relevant software and firmware updates... incorporates flaw remediation into the configuration management process."
SI-2 enhancement (2) requires you to "employ automated mechanisms to determine the state of system components with regard to flaw remediation." At AI-scale discovery rates, manual tracking becomes impossible. You need automated dependency scanning and vulnerability correlation.
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities)
"Information about technical vulnerabilities of information systems in use should be obtained, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken."
The key word is "evaluated." You're not required to patch every vulnerability immediately. You're required to evaluate your exposure and take appropriate measures—which might include patching, implementing compensating controls, accepting the risk, or isolating the affected system.
Lessons and Action Items for Your Team
1. Build a Decision Framework Before You Need It
Document your criteria for prioritization now, while you're not overwhelmed. Evaluate each vulnerability against exploitability, exposure to untrusted input, existing security controls, and business impact. Assign a priority score. Patch the high-scoring items first.
Your framework should answer: "If we can only patch 10% of our backlog this month, which 10% matters most?" Make that decision based on risk, not guilt.
2. Map Your Dependency Tree
Run npm audit, pip-audit, or equivalent for every repository. Export the results. Build a database of what you're actually running. You can't make patching decisions about dependencies you don't know exist.
For compiled languages, maintain a software bill of materials (SBOM) in CycloneDX or SPDX format. Update it with every build. Your vulnerability scanner should ingest your SBOM, not guess at your dependencies.
3. Instrument Your Exposure
For each critical dependency, document: Does it process untrusted input? Is it exposed to the internet? What security controls sit in front of it? A vulnerability in a library that only processes internal configuration files is not the same risk as a vulnerability in your request parser.
This exposure mapping lets you make rational decisions when you can't patch everything immediately.
4. Automate Correlation Between Disclosures and Inventory
When a new vulnerability is disclosed, you should know within minutes whether you're running the affected version. Set up automated scanning that correlates CVEs and GitHub Security Advisories against your SBOM. Alert on matches. Don't wait for the public advisory—monitor maintainer repositories and security mailing lists.
5. Accept That You'll Carry Risk
At a 16.5:1 discovery-to-repair ratio, you will have unpatched vulnerabilities in production. That's not a moral failure—it's arithmetic. Your job is to ensure the unpatched vulnerabilities you're carrying are the lowest-risk ones, and that you have compensating controls where possible.
Document your risk acceptance decisions. When you choose not to patch a medium-severity vulnerability in a library that's only called from internal services behind authentication, write down why. Your auditor needs to see that you made a decision, not that you ignored the finding.
The AI vulnerability discovery gap isn't going away. Your response process needs to assume that discovery will always outpace remediation and build decision frameworks that let you manage risk under those constraints.
