The Patch Bottleneck
When Mythos launched, the dominant fear was that attackers would discover zero-days faster than defenders. Seven months of data point to a different and more uncomfortable problem.
Defenders are discovering vulnerabilities faster than anyone can fix them.
This chapter looks at what the remediation data actually shows, why exploitation of AI-found bugs has stayed low so far, why that will not last, and how to rebuild a patch pipeline for the new pace.
The Old Lifecycle
For most of the past two decades, the vulnerability lifecycle ran on a predictable clock:
| Phase | Typical duration |
|---|---|
| Discovery by a researcher | Weeks to months |
| Proof-of-concept exploit | Days to weeks |
| Coordinated disclosure to the vendor | Days |
| Vendor fix and advisory | 30 to 90 days |
| Customer testing and deployment | 1 to 4 weeks, often longer |
| Discovery to broad protection | Roughly 4 to 12 months |
Enterprise patch programs, change boards and SLAs were all designed around that clock.
The New Lifecycle
AI compressed the left side of that table and left the right side almost untouched.
| Phase | Traditional | With AI |
|---|---|---|
| Discovery | Weeks to months | Hours to days |
| Exploit development | Days to weeks | Hours, sometimes minutes |
| Weaponization | Days to weeks | Near-immediate for skilled operators |
| Vendor fix | 30 to 90 days | Largely unchanged |
| Deployment | 1 to 4 weeks | Largely unchanged |
The asymmetry is the whole problem. The steps that belong to attackers got faster. The steps that belong to maintainers and enterprises did not.
CrowdStrike's 2026 report adds an uncomfortable number: a 42% year-over-year increase in zero-days exploited before public disclosure. Mandiant estimates the mean time to exploit at minus seven days. For a growing share of real-world exploitation, there is no patch window at all.
What the Remediation Data Shows
Anthropic's own numbers tell the story most clearly.
- Glasswing partners verified at least 129,000 vulnerabilities between April and July 2026, more than 33,000 of them critical or high.
- Anthropic's open-source scanning found 5,500 more through October.
- Of the 6,157 open-source findings Anthropic had disclosed to maintainers across 591 projects, 516 had been patched upstream as of October 2, to Anthropic's knowledge. That is roughly 8%, and "patched upstream" does not mean installed by the people running the software.
- Anthropic says the partner total is likely an undercount, because it comes from survey data from only some partners.
Open-source maintainers did not suddenly become slow. Many critical projects are maintained by a handful of volunteers. A single scanning campaign can hand one of them more valid security reports in a week than they normally receive in years. Each still needs reproduction, a fix, review, a release and coordination with downstream distributions.
Anthropic acknowledged this by funding open-source security organizations at launch and, through the year, expanding support for maintainers. That helps. It does not change the arithmetic: discovery is parallel and cheap; fixing is serial and human.
Why Exploitation Has Stayed Low, For Now
Here is the counterweight, and it matters for how you plan.
VulnCheck reviewed 1,061 publicly attributed AI-assisted discoveries from Glasswing and the Berkeley Vulnerability Research Initiative. By mid-2026, 14 of them, 1.3%, were confirmed as exploited in the wild, about the same rate as across all vulnerabilities in its dataset. Only 126 had become published CVEs, and one of those, a critical SQL injection in Ghost CMS (CVE-2026-26980), was exploited. For scale, VulnCheck logged 495 known exploited vulnerabilities in the first half of 2026.
Why so low, given everything in Chapters 1 through 3?
- Most findings are still under coordinated disclosure. Attackers cannot exploit what they do not know about, and much of the backlog is private.
- Exploitation still takes intent and operational work. Criminal groups weigh effort against payoff. Most of the newly found bugs are in components that are not yet worth their time.
- Attackers have easier options. Stolen credentials, phishing and long-known edge-device CVEs still work. Why build a novel kernel chain when a leaked API key opens the door?
My analysis: this is a temporary equilibrium, not a stable one. Three things will break it. First, as disclosures go public, every patch diff becomes a roadmap to the bug, and models are very good at reading diffs. Second, attackers with capable open-weight models will run their own discovery and keep the results private. Third, as the easy doors close, the economics push attackers toward the harder ones that AI now makes affordable.
The window between "lots of bugs found" and "lots of bugs exploited" is the time you have to fix your pipeline. Treat it that way.
Where Enterprise Patching Breaks
When I ask security leaders where patches stall, the answers are consistent:
- Testing capacity. Regression testing built for one critical patch a week does not absorb ten.
- Change management. Approval chains designed for predictability add days before work starts.
- Dependency tangles. One library update forces updates across dozens of services, and the test matrix multiplies.
- Ownership gaps. Nobody knows who owns the service running an old version of the vulnerable component.
- People. ISC2 continues to report a global cybersecurity workforce gap measured in millions, and most teams report budget shortfalls on top of it.
None of these are AI problems. AI simply raised the cost of each one.
A Speed-First Patching Model
The answer is not a heroic team. It is tiers, automation and decisions made before the incident. These targets are my recommendation, based on what I have seen work, not an industry standard.
Tier 1: Automated, same day
Scope: development and staging environments, non-customer-facing internal tools, container base images, serverless runtimes, developer endpoints.
How: dependency bots open pull requests automatically; tests gate the merge; images rebuild on base updates; no human approval for passing changes.
This removes the highest-volume, lowest-risk work from human queues entirely.
Tier 2: Accelerated, within 72 hours
Scope: standard production systems.
How:
- Pre-approved emergency change windows the security team can invoke without a full change board.
- Automated regression suites that start the moment a patch lands.
- Canary deployment to a small slice of traffic, with automatic rollback on error-rate or latency regressions.
- Human review after deployment, not before, for patches that pass automated gates.
Tier 3: Coordinated, seven days maximum
Scope: crown jewel systems where a bad patch could cause more damage than the bug.
How: dedicated test environments that mirror production, pre-written playbooks, executive escalation paths, and compensating controls live from hour one while testing runs.
Even here, seven days is the ceiling, not the target.
Prioritize by exploitation signal, not volume
You will not patch everything. Rank with data that predicts real exploitation:
- Known exploitation: CISA's Known Exploited Vulnerabilities catalog, VulnCheck's KEV and vendor threat intelligence.
- Exploitation likelihood: EPSS scores, which estimate the probability of exploitation in the next 30 days.
- Exposure: internet-facing, reachable from untrusted input, or sitting on an attack path from Chapter 3.
- Asset value: what breaks or leaks if this system falls.
A medium-severity bug on an internet-facing identity service with an EPSS spike outranks a critical bug in an isolated batch job.
Compensating Controls for the Gap
There will always be time between knowing about a flaw and having the fix deployed. These controls carry you across it:
- Virtual patching at the WAF or API gateway. Block known exploit patterns for a specific flaw before the code changes.
- Runtime protection. RASP and eBPF-based runtime security can stop exploitation behavior, such as unexpected process execution, even for flaws nobody has identified yet.
- Network segmentation. Of all the controls I relied on while running large-scale identity infrastructure, segmentation saved us in more incidents than any other. Limiting what a compromised component can reach turns a breach into an incident.
- Behavioral detection. Watch for what attackers do after exploitation: privilege changes, new outbound connections, credential access. You do not need to know the bug to see the consequences.
- Attack surface reduction. Every service you shut down is a patch you never have to ship. Decommission aggressively.
Browsers deserve special mention here, because they are the most exposed software most employees run and they ship fixes on their own cadence. My browser security analysis covers how to manage that layer. And if your patch backlog includes authentication components, moving users to phishing-resistant credentials, as described in my FIDO2 implementation guide, removes a whole category of urgent fixes.
Measure What Matters
Before you change anything, measure your actual numbers for the last ten critical vulnerabilities in your environment:
- Time from public disclosure to your awareness.
- Time from awareness to a tested fix.
- Time from tested fix to full production coverage.
- Percentage of critical assets with a named owner.
Include weekends, holidays and change board delays. Most teams discover that their real number is two to four times their policy number. That gap is your project plan.
Key takeaways
- AI accelerated discovery and exploitation, but not fixing or deploying.
- Glasswing partners verified 129,000+ vulnerabilities, while only about 8% of disclosed open-source findings were patched upstream by October.
- In-the-wild exploitation of AI-found bugs is still low. Treat that as a temporary window.
- Tiered patching, with same-day automation, 72-hour production targets and a seven-day ceiling for crown jewels, is achievable.
- Prioritize by real exploitation signals and attack paths, and use compensating controls to cover the gap.
Patching faster closes one door. The fastest-growing attack surface in most enterprises is not code at all. It is the credentials that machines and AI agents use to talk to each other. That is Chapter 5.