Claude Mythos: 26K Findings and the Human Triage Bottleneck

Claude Mythos: 26K Findings and the Human Triage Bottleneck

Project Glasswing was supposed to demonstrate what happens when frontier AI is pointed at one of cybersecurity's oldest problems: finding vulnerabilities at scale.

It worked.

Maybe too well.

Anthropic's vulnerability disclosure dashboard currently lists 26,153 candidate findings generated across Mythos and other Claude-based security work. But that number does not mean 26,153 confirmed vulnerabilities.

The more interesting story is what happens after the model finds something.

Only a fraction of those candidates make it through external review, disclosure, maintainer acknowledgement and remediation. Anthropic itself describes independent human triage and review as a rate-limiting step.

That changes the question.

The hard part may no longer be finding bugs.

It may be deciding which ones are real, reporting them correctly, getting maintainers to act, and making sure the fix actually reaches users.

First: 26,153 does not mean 26,153 vulnerabilities

This distinction matters.

Anthropic's current Vulnerability Disclosure dashboard reports 26,153 findings candidates. The figure includes findings from Mythos Preview, other Mythos-class models and other Claude models participating in the programme.

Anthropic also reports that:

• 5,008 findings were reviewed by external security firms
• 4,576 were confirmed valid within that reviewed set
• 2,300 vulnerabilities were reported to maintainers
• 1,815 were acknowledged
• 421 were patched upstream

Anthropic describes the 4,576 / 5,008 figure as a true-positive metric, but also warns that it is only one proxy for programme impact. A confirmed finding can include a bug that had already been reported elsewhere or one that a maintainer ultimately decides not to fix.

So the pipeline is not:

26,153 vulnerabilities → 202 fixes

It is closer to:

26,153 candidates → human review → confirmed findings → disclosure → acknowledgement → upstream patches

And every stage loses findings or takes time.

That distinction is the most important correction to the headline numbers surrounding Glasswing.

Where the 202 number actually comes from

The 202 fixed figure is real, but it comes from a different counting layer.

VulnCheck analysed Anthropic's public disclosure ledger and found 2,736 entries in the main ledger. Of those entries:

• 202 were marked fixed
• 245 were withdrawn
• 2,096 were disclosed but not confirmed fixed
• 191 were still pre-disclosure
• 18 had already been patched before Anthropic reported them

That makes 202 fixed findings only about 0.8% of the 26,153 candidate findings.

But that percentage should not be presented as Anthropic's overall remediation rate.

Why?

Because Anthropic's dashboard currently reports 421 patched upstream, while the ledger analysis by VulnCheck reports 202 fixed entries. These are different datasets/counting layers, with different scopes and update behaviour.

VulnCheck also identified discrepancies between the main ledger and its CVE/GHSA sub-ledgers.

That does not prove Anthropic's data is wrong.

It does mean the numbers should be read carefully rather than treated as one perfectly reconciled database.

The funnel is the real story

The numbers become more useful when you stop treating them as a scoreboard.

Think of vulnerability discovery as a funnel:

AI-generated candidates
        ↓
Human / external review
        ↓
Confirmed vulnerability
        ↓
Disclosure
        ↓
Maintainer acknowledgement
        ↓
Patch
        ↓
Patch reaches users

Anthropic's dashboard makes the bottleneck explicit: human triage and review are limiting how quickly findings can move through the pipeline.

This is a very different problem from traditional vulnerability research.

Historically, discovering a vulnerability was often the expensive part.

With capable AI systems, discovery can become cheap enough that the expensive part moves downstream.

Someone still has to reproduce the bug.

Someone has to determine whether it is actually exploitable.

Someone has to decide how serious it is.

Someone has to write a useful disclosure.

Someone at the affected project has to understand the report.

Someone has to build and ship a fix.

And then someone has to deploy it.

AI can accelerate parts of that process.

It does not automatically eliminate the queue.

Mythos can overrate severity

The ledger also exposes an interesting disagreement between Claude's severity assessment and maintainer assessment.

For findings where both ratings were available, VulnCheck reported that Claude classified 91.5% as critical or high, while maintainers classified 51.3% that way.

That gap does not necessarily mean the model is useless at severity assessment.

It means an AI-generated severity label should not be treated as the final decision.

A model sees a potentially dangerous technical condition.

A maintainer has to consider the actual product, deployment assumptions, exploitability, affected versions, attack surface and practical impact.

Those are not always the same thing.

And when thousands of findings arrive at once, severity inflation becomes expensive.

A queue filled with "critical" findings is not automatically a useful queue.

Curl shows why validation matters

One example from the Glasswing reporting makes the problem easier to understand.

VulnCheck highlighted an experience involving curl maintainer Daniel Stenberg. Five Mythos reports were investigated, but the reports ultimately reduced to:

• one real vulnerability
• three false positives
• one issue that was a bug but not a security vulnerability

That is not an argument against AI vulnerability discovery.

It is an argument for validation.

If a system can produce thousands of plausible reports, even a relatively high-quality detector can create substantial work for maintainers.

The question becomes:

How cheaply can we separate useful findings from everything else?

That is a much more interesting engineering problem than simply asking how many vulnerabilities an AI can find.

AI security scanners have the same problem

The problem is not unique to Mythos.

Dark Reading reported an experiment from Contrast Security in which three AI security scanners were run three times against the same 50,000-line codebase.

The results varied between runs.

A Sonnet-based scanner reproduced only 17% of its own findings across the three runs.

An Opus-based scanner reproduced 25% of its own findings, while the number of findings varied by roughly 30% between the best and worst runs.

Across the scanners, only around 5% of findings were shared.

That does not mean AI scanners are incapable of finding real vulnerabilities.

It demonstrates something defenders should already understand:

a generated finding is an input to investigation, not proof.

The more findings a system produces, the more important reproducibility becomes.

Scanning became cheap. Triage did not.

The economics make the problem even clearer.

According to figures reported by Dark Reading from the same Contrast Security project, scanning a 2-million-line codebase cost roughly $315 in API charges, while triaging the resulting output was estimated at about $128,000.

The exact economics will obviously vary by model, tooling, codebase and workflow.

But the direction is important.

If compute keeps getting cheaper while AI agents become better at exploring large codebases, the cost of generating findings can fall dramatically.

Human engineering time does not automatically fall at the same rate.

That creates a new security bottleneck:

finding problems faster than people can understand them.

This is not just an Anthropic problem

Project Glasswing itself was launched as a collaboration involving Anthropic and a range of technology and security organisations.

Anthropic announced the programme in April 2026 and described Mythos as part of an effort to identify vulnerabilities across widely used software. In its May update, Anthropic said roughly 50 partners had already found more than 10,000 high- and critical-severity vulnerabilities, while warning that progress was increasingly constrained by verification, disclosure and patching capacity.

That last part is the important one.

The industry has spent years improving vulnerability scanners, SAST, DAST, fuzzing and automated testing.

Agentic AI adds another layer of automation.

The result may not be fewer security findings.

It may be far more findings.

And that means security teams need better ways to process them.

What security teams should take from this

Triage by evidence, not by the model's severity label

A model saying "critical" should trigger investigation, not automatic escalation.

Look for:

• reproducible behaviour
• affected versions
• reachable attack paths
• realistic attacker prerequisites
• exploitability
• evidence of exploitation
• exposure in your own environment

Known exploited vulnerabilities are especially useful because exploitation evidence gives defenders something stronger than an AI-generated severity prediction.

Automate confirmation where possible

The answer is not to put a human in front of every raw scanner result forever.

Build automation around the repetitive parts:

• reproduce the finding
• test affected versions
• compare vulnerable and patched behaviour
• collect logs
• enrich asset ownership
• deduplicate reports
• group related findings

Then keep human judgement where context matters.

AI should reduce the queue.

It should not simply generate a larger queue.

Report useful findings quickly

The ledger contains an interesting warning sign: 18 findings were already patched before Anthropic reported them in the dataset analysed by VulnCheck.

That means discovery timing matters.

A vulnerability sitting inside an internal queue does not help the maintainer who needs to fix it.

Fast, reproducible and actionable disclosure is still part of the security work.

Patch the boring stuff

There is an irony here.

The more impressive AI vulnerability discovery becomes, the more valuable ordinary patch management becomes.

If AI can continuously search thousands of projects for weaknesses, defenders need to assume that publicly exposed and outdated dependencies will eventually receive more attention.

You do not need an autonomous SOC to benefit from that lesson.

You need:

• accurate asset inventory
• dependency visibility
• patch management
• vulnerability prioritisation
• network segmentation
• good identity controls
• useful logging
• tested incident response

The bottleneck moved

For decades, vulnerability research operated under a scarcity model.

Finding a serious bug required expertise, time and effort.

AI changes that equation.

The supply of plausible findings can now grow much faster than the supply of people capable of validating and fixing them.

That does not make human security researchers obsolete.

It makes their role different.

The valuable skill increasingly becomes knowing which findings deserve attention, how to prove them quickly, how to communicate them clearly, and how to get the right fix shipped.

That is why the most interesting number in the Glasswing story may not actually be 26,153.

It may be the distance between:

finding something

and

getting something fixed.

AI is getting very good at the first part.

The second part is still stubbornly human.

Sources

• VulnCheck: The Anthropic Glasswing Receipts Are Starting to Trickle In
• Anthropic: Anthropic Vulnerability Disclosure Ledger
• Dark Reading: Mythos Vulnerability Firehose Hits a Human Bottleneck
• Anthropic: Project Glasswing
• Anthropic: Glasswing Initial Update