A seven-month audit by VulnCheck finds that Anthropic’s Project Glasswing has logged nearly 38,000 candidate vulnerabilities, but only 217 appear as fixed in its public ledger. The bigger story is about who pays for triage when machines can find bugs faster than people can check them.
What happened
On 9 November, Patrick Garrity, a vulnerability researcher at VulnCheck, published his latest review of Project Glasswing. This is the Anthropic programme that puts its frontier models in the hands of researchers to hunt for flaws in critical software, much of it open source, and report them to maintainers. Garrity has tracked the project since April, cross-checking Anthropic’s own disclosure ledger against CVE records, GitHub security advisories and Linux kernel commits.
His numbers are blunt. Anthropic’s dashboard, last updated on 2 November, lists 37,966 findings. Only 7,349 of them (19.4 per cent) have been made public, and just 217 are marked as fixed. A further 1,654 have been flagged as duplicates and 419 withdrawn. Between his September review and the November update, Anthropic added roughly 11,800 findings to its count, while the number marked fixed rose by only 15.
Infosecurity Magazine reported the analysis on 11 November and said Anthropic had not replied to a request for comment. A QbitAI report republished by 36Kr on 12 November cited different figures from Anthropic’s own disclosures: 6,376 findings reviewed by external experts, 6,009 judged valid, 5,087 reported to maintainers and 629 with upstream patches. That article notes that fix totals vary with how each party defines a fix. It also points out that VulnCheck sells vulnerability intelligence, so it has a commercial interest in the debate.
The detail
Garrity has attributed 442 CVEs to Anthropic so far. That is about 63 a month and roughly 0.5 per cent of the 93,450 CVEs published in 2026. Checked against VulnCheck’s catalogue of known exploited vulnerabilities, only two of those 442 have been used in real attacks. He also challenges Anthropic’s claimed true positive rate, which has risen from 90.8 per cent at the ledger’s launch in May to 94.2 per cent now. In his view that is hard to square with duplicates outnumbering fixes by more than seven to one.
The disclosure pipeline is where the strain shows most clearly. In October, Anthropic said it had produced more than 29,000 candidate findings, of which humans had checked roughly 6,000, and admitted it was “bottlenecked on our human capacity to validate these findings”. It responded by launching an Open Source Security Scanner, which lets projects request scans and work through the model-generated reports themselves. Anthropic also said it had already sent close to 5,000 unverified reports to maintainers who had asked for everything in bulk.
The curl project shows what that looks like at the receiving end. On 6 November, maintainer Daniel Stenberg said curl had received 45 reports from Anthropic. Of the 34 published so far, 19 were judged not to be vulnerabilities at all and six were confirmed as low severity, with the other nine still awaiting assessment. Stenberg has chosen to handle low and medium issues openly on GitHub and to release them gradually to ease the load on his team. To be fair to Anthropic, 36Kr reports that Claude did find a serious use-after-free bug in curl in September, which Stenberg described as one of the most serious curl vulnerabilities in years. The problem is not that the model never finds real bugs. It is the cost of separating those bugs from the noise.
Why it matters for UK organisations
Almost every UK organisation runs open source code, usually far more of it than its asset register shows. Patches for that code come from volunteer or thinly staffed maintainer teams. When those teams spend their week rejecting machine-generated reports, real fixes take longer. Garrity’s figures suggest that the most important number in AI-assisted bug hunting is not how many issues a model flags, but how many ever reach a released patch.
The same pressure applies to any organisation running a vulnerability disclosure programme or a bug bounty. The NCSC has long encouraged UK organisations to publish a clear reporting route for researchers. Some bounty platforms have spent this autumn experimenting with report fees and stricter intake rules, largely in response to AI-generated volume. If a well-funded AI lab struggles to validate its own output, a mid-sized UK firm with one person reading the security inbox will struggle too.
There is also a supplier question. Under the Cyber Security and Resilience Bill, more managed service providers and essential service operators are likely to need to show that they handle vulnerabilities in a structured way. “We received thousands of reports and could not triage them” is not a position any regulator will accept.
Expert view
In my experience, the hardest part of a security assessment has never been producing findings. Scanners have produced thousands of them for twenty years. The skilled work lies in confirming exploitability, working out business impact and writing something a developer can act on. A report that moves that work onto the recipient has not saved anyone time. It has simply shifted the cost.
That does not make Glasswing worthless. Real bugs are being found, some of them serious, and the curl use-after-free proves the point. The lesson I would draw is that a finding count is a vanity metric. When we test, clients care about validated, reproducible issues with a fix path, and open source maintainers deserve the same standard. Transparent ledgers are welcome, but they only build trust if outsiders can check the numbers and find that they add up.
The duplicate figure worries me most. When findings sit unreported for weeks, someone else often reports the same flaw first. That points to a backlog, and a backlog of known but undisclosed vulnerabilities is a risk in its own right.
What to do now
- Know your open source estate. Keep a current software bill of materials for key applications so you can tell quickly whether a newly fixed library affects you. This supports the Cyber Essentials security update management control.
- Prioritise on evidence of exploitation. Rank patching by known exploitation and exposure, not by headline severity or the volume of AI-reported issues.
- Harden your own intake. If you run a VDP or bounty, require a reproducible proof of concept, ask reporters to declare AI use, and set triage service levels you can actually meet. Publish a security.txt file so genuine reporters reach the right people.
- Use AI scanning with discipline. If your developers run AI code scanners, make human validation mandatory before anything goes into a ticket queue or to an upstream project.
- Support the maintainers you rely on. Funding, staff time or upstream contributions to critical dependencies make patches more likely to arrive when you need them.
Bottom line
VulnCheck’s audit does not show that AI bug hunting has failed, but it does show the bottleneck has moved from finding flaws to proving them. Until AI-generated reports arrive validated, the cost will keep landing on the maintainers and security teams least able to absorb it. UK organisations should measure success by fixed and exploited vulnerabilities, not by reported ones.
