Short answer: Anthropic’s 26 August 2026 dashboard reports 2,300 disclosed vulnerabilities across 392 open-source projects, with 421 patched upstream and 462 CVE or GHSA identifiers assigned. Those numbers show that AI-assisted discovery can create security work faster than people can validate, coordinate and remediate it. A safe programme keeps useful research moving while operating disclosure as a measured queue with human validation, submission pacing, clear ownership and a final check on downstream patch adoption.
Anthropic’s new vulnerability dashboard invites an easy calculation. Divide 421 upstream patches by 2,300 disclosed findings and the result is 18.3%.
The arithmetic is correct, but it cannot support an 18.3% patch success rate.
The dashboard is a snapshot of findings with different ages and routes through disclosure. Some reports arrived recently. Some maintainers have not replied. Others may have fixed a bug without issuing an advisory. A published patch also says nothing about whether downstream users installed it. Treating the four headline numbers as one clean funnel hides the part security teams need to understand: time and ownership between states.
What Anthropic’s vulnerability dashboard actually reports
Anthropic says it began using an early Claude Mythos Preview snapshot to find flaws in open-source software in February 2026. External security firms then reproduced and assessed candidate findings before reports went to maintainers. The programme works with Ada Logics, Anvil, Calif.io, Doyensec, Ophion Security and Trail of Bits.
As of the 26 August snapshot, the public totals were:
- 2,300 disclosed vulnerabilities across 392 open-source projects.
- 421 findings patched upstream, meaning a patch landed after the report was sent.
- 462 identifiers assigned: 177 CVE records and 285 GitHub Security Advisories. One finding can have both.
- A public ledger containing cryptographic commitments for findings still moving through disclosure.
Anthropic also states that independent human triage and review is the rate-limiting step. Its description goes further: security partners have confirmed additional real bugs that have not yet reached maintainers because reporting capacity is limited.
That admission matters more than the raw total. The system can produce useful candidates faster than the disclosure operation can safely absorb them.
Why 421 divided by 2,300 is not a patch rate
A useful conversion rate needs a defined cohort and enough time for every item to reach the outcome. This dashboard provides neither. The disclosed total combines old and recent reports. The patched count is a lagging state. Anthropic’s policy normally gives maintainers up to 90 days before public disclosure, allows a 14-day extension when a fix is progressing, and aims for a shorter seven-day timeline when a critical issue is under active exploitation.
Patch production is not the final outcome either. A maintainer can merge a fix while released packages, Linux distributions, container images and downstream forks remain vulnerable. Anthropic explicitly notes that “patched upstream” does not guarantee broad installation.
There are other wrinkles. The dashboard’s true-positive definition includes duplicates and valid findings that fall outside a project’s threat model or are marked “won’t fix”. Some reports go directly to maintainers without the same external check because the maintainer requested untriaged results. A CVE and a GHSA can refer to the same underlying finding. Each number answers a different question.
The honest reading is narrower: at the snapshot date, Anthropic had disclosed far more validated security work than had reached a recorded upstream patch. The public data does not tell us that 81.7% of maintainers failed.
AI raises the arrival rate while remediation stays human
Traditional vulnerability programmes already struggle with noisy reports, duplicate work and maintainer fatigue. AI changes the volume and cost of the first stage. It can inspect more code, form more hypotheses and keep searching after a human researcher would have moved to another target.
The rest of the job stays stubbornly social and technical. Someone must reproduce the issue against the correct revision. A report needs a clear threat model and a minimal proof. The maintainer has to understand the affected path, design a safe fix, add a regression test and cut a release. Users then need to find and deploy that release without breaking production.
This creates a queueing problem. If candidate generation doubles while validation and maintainer throughput stay flat, the backlog grows even when model precision improves. A 91% true-positive rate does not solve a capacity limit. High-confidence work can still wait for an available reviewer or an already overloaded maintainer.
Security teams know this pattern from scanners. More findings feel like more coverage until the queue is old enough that nobody trusts it. AI discovery raises the stakes because a good system may find real, high-impact bugs at a rate that makes careless bulk disclosure harmful.
A finding needs seven owned transitions
I would separate the work into seven states. The names are less important than making every handoff visible.
1. Find: record a candidate, not a vulnerability
A model output begins as a hypothesis. Store the repository revision, affected file and function, assumed threat boundary, model provenance and the smallest claimed impact. Do not assign a severity that implies human confirmation.
2. Verify: reproduce and bound the claim
A security researcher should confirm reachability, attacker prerequisites and impact against the named revision. The report needs to distinguish a real bug from a duplicate, dead code path, unsupported configuration or behaviour outside the project’s threat model.
This is where a high-volume programme earns trust. A polished model explanation is not evidence. A reproducible case, precise source location and clear impact are.
3. Pace: match submissions to risk and capacity
Anthropic’s policy says it does not send a large volume of findings to one project without agreeing on a pace the maintainer can sustain. That is an operational control, not courtesy. Flooding a small project with dozens of valid reports can delay its response to the most dangerous one.
Severity, exploitability, project reach and active exploitation should set priority. The queue also needs an age limit so a medium-severity report does not disappear behind a constant stream of newer critical findings.
4. Notify: establish a real owner
A sent email is not ownership. Record whether the maintainer acknowledged the report, who is coordinating it, which disclosure clock applies and when escalation begins. Anthropic’s default policy aims to escalate to an external coordinator when a maintainer has not responded within 30 days.
Projects can make this easier with a current SECURITY.md, private reporting enabled, supported-version policy and at least two people able to receive security mail. A vulnerable project with one exhausted maintainer has a governance risk as well as a code defect.
5. Patch: fix the invariant, not the sample input
The patch should address the broken security property and include a regression test. Candidate fixes from AI can help, but the maintainer still owns compatibility, design and release risk. A narrow blocklist may stop the provided proof while leaving the same trust mistake reachable through another path.
Track the commit, review status, test evidence and any mitigation available before release. For an ecosystem-wide pattern, coordination may need to happen across several projects before details become public.
6. Ship: connect the fix to an installable release
A merged commit is useful to developers and invisible to most users. Link the fix to a version, advisory and supported upgrade path. State whether a configuration workaround exists and what evidence operators can use to check exposure.
Anthropic’s policy generally waits 45 days after a patch before publishing full technical detail. The purpose is to give downstream users time to deploy. That window only helps when advisories reach the people who own upgrades.
7. Adopt: verify that risk fell in deployed systems
Software composition data, image inventories and package telemetry should show where the vulnerable version still runs. For high-impact findings, teams need an adoption view by business service and exposure, not just a count of repositories with an automated pull request.
This is the missing end of many disclosure dashboards. Discovery, disclosure and patch publication are producer-side events. Risk changes when vulnerable deployments are removed, isolated or mitigated.
The cryptographic ledger solves one trust problem
Anthropic publishes a SHA-3-512 commitment for each validated report when the disclosure clock begins. The sealed record includes the project, source location, discovery time, technical details, reproduction steps, severity assessments and a hash of the proof-of-concept artefact. Details stay hidden while the finding is private. After disclosure, the preimage can be checked against the earlier commitment.
This gives the programme a tamper-evident history. Anthropic can prove that a particular report existed at a particular stage without exposing the bug before the maintainer has time to act. Withdrawn and merged records remain visible rather than silently disappearing.
The ledger does not validate the finding by itself. A hash can prove that a document has not changed; it cannot prove that the document’s technical claim is correct. Human reproduction and maintainer assessment still carry that burden.
What a disclosure programme should measure
Raw discoveries reward the fastest part of the system. Better metrics expose where risk waits:
| Metric | Question it answers | Failure signal |
|---|---|---|
| Validation lead time | How long from candidate creation to human reproduction? | High-severity candidates ageing without review. |
| Valid backlog by age | How much confirmed work has not reached a maintainer? | Old reports hidden behind a healthy true-positive rate. |
| Acknowledgement time | How long until a project accepts ownership? | Reports repeatedly sent to abandoned or incorrect contacts. |
| Patch lead time | How long from acknowledgement to an upstream fix? | Complex fixes with no engineering support or agreed mitigation. |
| Release lead time | How long from fix commit to a consumable version? | Merged patches stranded outside a release. |
| Adoption exposure | Where do vulnerable versions remain deployed? | A published fix with broad internet-facing exposure unchanged. |
Show these by severity and project capacity. A median alone can look healthy while one critical report waits at the tail. The queue should also record duplicates, “won’t fix” decisions and threat-model disagreements without treating them as researcher failure or maintainer negligence.
A practical response for security teams and maintainers
If your organisation is adding AI-assisted vulnerability discovery, budget the downstream work before increasing scan volume. Set a weekly validation capacity, a maximum unreviewed age for high-severity candidates and a submission pace per project. Fund researchers who can turn a model hypothesis into a report a maintainer can act on.
Maintainers should test the intake path before a real report arrives. Confirm that SECURITY.md points to a monitored channel, private disclosure works, supported versions are clear and somebody besides the primary maintainer can coordinate a fix. Decide how emergency releases are signed and published.
Platform teams can reduce the burden with shared triage, release automation and downstream inventory. They should resist one tempting shortcut: measuring success by the number of findings delivered. A disclosure programme that produces 10,000 valid reports and leaves maintainers unable to act has created knowledge, not proportional risk reduction.
Frequently asked questions
Did Anthropic find 2,300 vulnerabilities with Claude?
Anthropic’s dashboard says Claude Mythos Preview and other Claude models contributed candidates to a programme that disclosed 2,300 vulnerabilities across 392 open-source projects by 26 August 2026. External security firms or Anthropic researchers reviewed most reports before disclosure.
Were only 18.3% of Anthropic’s disclosed vulnerabilities patched?
The snapshot lists 421 upstream patches and 2,300 disclosed findings, so 421 is 18.3% of 2,300. That does not establish an 18.3% patch success rate. The findings have different ages, some follow different review paths, and upstream patching does not measure downstream deployment.
Why does AI vulnerability discovery create a disclosure bottleneck?
Candidate generation can scale with model inference and compute. Validation, maintainer coordination, patch design, testing and release work depend on scarce human attention and project-specific knowledge. When arrival rate grows faster than those stages, the backlog grows.
What is Anthropic’s commitment ledger?
It is a public record of SHA-3-512 hashes for sealed vulnerability reports. The commitment proves that a report existed in a fixed form before public disclosure. Once details are revealed, readers can compare the published preimage with the earlier hash.
What should organisations measure instead of total findings?
Track candidate-to-validation time, age of the confirmed backlog, maintainer acknowledgement time, patch and release lead time, and the remaining exposure of vulnerable versions in deployed systems.
The decision after discovery
Anthropic’s dashboard is evidence that AI can supply serious vulnerability work at a new volume. It is also a warning about the shape of the next constraint. More discovery increases safety only when the disclosure system can preserve quality, protect maintainers from overload and carry fixes into deployed software.
For a team considering a larger AI security programme, I would ask for one diagram before approving more model capacity: who owns every handoff from candidate to installed patch, and how long can a critical finding wait at each one? If that answer is missing, the programme is scaling its queue faster than its security outcome.
Primary sources
- Anthropic’s coordinated vulnerability disclosure dashboard, snapshot updated 26 August 2026.
- Anthropic, “About this dashboard”, including glossary, partner list and commitment-verification method.
- Anthropic’s coordinated vulnerability disclosure policy, updated 6 March 2026.
- Continue with my authorised security write-ups for practical attack-path methodology.
One next action
If you run an agent that executes tools, AgentCrash is an open-source harness that crash-tests it in a synthetic workplace: synthetic tools, visual evidence and regression tests. It is built for exactly this problem, turning a containment claim into something you can run against the system instead of arguing about it in review.