By October 2, 2026, Anthropic’s coordinated vulnerability disclosure dashboard listed 6,157 disclosed vulnerabilities across 591 open-source projects. Anthropic says Claude models, including an early snapshot of Claude Mythos Preview, found candidate issues; external security research firms triaged many before reports went to maintainers. The dashboard is useful as an inventory, but its totals describe different stages.
What the dashboard counts
Anthropic reports 29,439 discovered findings in the program, 6,123 candidates, and 5,674 reviewed by external security firms. The dashboard lists 92.7% as the true-positive rate across the 6,123 candidates. Those counts describe different stages, not interchangeable totals: a discovered finding is not automatically a validated vulnerability or a report to a maintainer.
The dashboard lists 6,157 findings disclosed, 5,103 acknowledged by maintainers, and 516 patched upstream, to Anthropic’s knowledge. It also lists 584 assigned identifiers: 219 CVEs and 365 GitHub Security Advisories. One finding can have both identifiers, and a project may ship a fix without publishing an advisory. Anthropic’s dashboard glossary defines “patched upstream” as a patch landing after the report was sent; it cautions that a released patch does not mean downstream installations have updated.
Human review is part of the process
Anthropic’s coordinated disclosure policy says reports generally reflect findings reviewed and confirmed by a human security researcher. The dashboard describes outside security firms as triage partners, but not every report followed the same route: some findings were sent directly to maintainers at their request, and the dashboard says those direct reports may contain false positives.
The policy sets a default 90-day disclosure timeline, with a possible 14-day extension when a maintainer is engaged and making progress. For actively exploited critical vulnerabilities, Anthropic targets seven days for a patch or mitigation. The policy also says Anthropic aims to pace submissions to what maintainers can absorb. This matters when interpreting a growing disclosure count: findings, reports, acknowledgments, and patches move through separate stages.
What operators should check
I would use the dashboard as a lead list, not as a verdict on a running system. Search it for software in your stack, then open the linked CVE or GHSA and confirm the affected product, version range, severity, and fixed version. Check the project’s release notes or security advisory before changing a deployment.
A project appearing in the ledger does not establish that every version is vulnerable. Nor does the 516 patched count say how many installations have applied updates. For systems you operate, compare the exact installed version with the advisory’s affected range, identify a fixed release or mitigation, and follow your normal test-and-rollout process. The dashboard is updated over time, so record when you checked it and verify the advisory’s current status.
No comments yet