40% of Fixable Vulnerabilities Still Aren’t Fixed After 180 Days

Anthropic’s security researchers pointed a model called Mythos at a pile of open source code and asked it to find bugs. It came back with 23,019 candidate vulnerabilities. Almost all of that was noise — only about 1,900 got a human review. But the ones that passed held up: north of 90% turned out to be real.

Here’s the number that actually matters, published November 2 in a report from the research group Echo on AI and vulnerability management: none of that review speed changes anything if 40% of vulnerabilities that already have a fix are still sitting unpatched 180 days later. Echo pulled this from 40,000 vulnerability lifecycles across 250 open source container projects, plus a survey of more than 80 security leaders. The headline isn’t that AI finds more bugs. It’s that finding more bugs was never the bottleneck.

The gap, in Echo’s own numbers

89% of the CVEs in Echo’s sample already had a fix available by the time anyone measured them. That’s not a close call — nine in ten vulnerabilities in this dataset were solvable the moment someone ran an update command. And still, 40% of the fixable ones were sitting in container images more than six months after the patch shipped. Not because no patch existed. Because nobody applied it.

Severity scoring doesn’t save you here either. Echo checked 27 published CVEs against real-world exploitability data and found severity discrepancies in 14 of them — over half. A bug rated low can be the one actually getting exploited in the wild; a bug rated critical can be the one nobody’s touched. If your patch queue is ordered by CVSS score alone, you’re prioritizing against data that disagrees with itself half the time.

The Mythos numbers above are worth sitting with for a second, because the same bottleneck shows up one step earlier in the pipeline. Mythos surfaced 23,019 candidate vulnerabilities, and only about 1,900 of those — roughly 8% — got a human review before anyone trusted the result. That’s not a flaw in Mythos specifically. It’s discovery being fast and cheap while review stays slow and expensive, which is exactly the same shape as the 89%-fix-available-but-40%-unpatched gap further down the pipeline. Every stage of this process can produce a result faster than a human can act on it, and stacking more AI discovery on top of an already-backed-up review and patch queue doesn’t close that gap. It makes the backlog bigger before anyone touches it.

Where the clock actually runs fast

The exploitation timeline tells a different story depending on where you look. Only about one in four exploited open source vulnerabilities got exploited within a day of disclosure — attackers mostly aren’t racing teams to the patch, they’re picking off whatever’s still open months later. Compare that to malicious package publishing: 65% of hijacked packages get flagged and disclosed within 24 hours of the bad version going live. The ecosystem is fast at catching an attacker sneaking in a new malicious package, and slow at getting an old, known, fixable bug off production systems. That mismatch sits backwards from where the real risk actually is.

The honest explanation for that mismatch probably isn’t laziness. Patching a dependency in a container image means rebuilding, retesting, and redeploying something that currently works, and “currently works” is a hard thing to risk on a Tuesday afternoon for a bug nobody’s actively exploiting yet. Flagging a malicious package, by contrast, is a one-time decision with no regression risk attached — pull it, block it, done. Both reactions make local sense. Stacked across an industry, they produce exactly the pattern Echo measured: fast triage for new threats, slow cleanup for old ones, and risk quietly concentrating in the second category because nobody’s incentives point at it.

What this means if you’re running an AI-assisted scanner

Mythos-style tools are going to keep showing up in security pipelines, and the top-of-funnel numbers will keep looking impressive — more candidates found, more coverage, more confidence that nothing slipped through review. None of that touches the problem Echo measured: a gap between “we know about this” and “we did something about this” that a 90%-accurate discovery model does nothing to close on its own. The practical move here is boring, and it isn’t a new tool. Pull your own vulnerability backlog and sort by age of available fix, not severity score. If something you could have patched in April is still open in November, that’s the number worth bringing to your team before the next AI scanner demo, not after.

The 90% accuracy rate on Mythos’s reviewed findings is genuinely good, and it’s a real sign that AI-assisted vulnerability discovery is past the hype phase. It just answers a question most security teams already have enough answers to. The one still open is operational, not technical — and no model ships a fix for an org chart that doesn’t own patch deployment.

One more thing worth doing before you adopt an AI-assisted scanner rather than after: time how long your last five patches sat between “fix available” and “fix deployed,” not between “found” and “fixed.” If that number is already measured in months, adding a faster discovery engine on top just moves the bottleneck earlier in the pipeline where it’s less visible, not away.

Sources

Security Boulevard: AI is accelerating vulnerability discovery — what happens next matters more (November 2, 2026, reporting on Echo’s 2026 vulnerability management report).