VulnCheck's Glasswing critique, checked: 7 of 45 Anthropic reports to curl were vulnerabilities, and 18 got fixed anyway

Patrick Garrity of VulnCheck has published his third progress check on Anthropic's Project Glasswing, and it is harsh. "After 7-months, Glasswing Overwelms Maintainers with Underwhelming Findings" (November 9) argues that Claude's vulnerability hunting has produced a sliver of this year's CVEs, that fixes have stalled while duplicates pile up, and that Anthropic's new OSS Scanner pushes triage onto maintainers. Its sharpest evidence is curl: of the first 34 published reports from a batch of 45, maintainer Daniel Stenberg's team had marked 19 "not a vulnerability", which Garrity turns into a "false positive rate" of 55.9%, against the 94.2% true-positive rate on Anthropic's dashboard.

We went through the same two sources Garrity uses, curl's GitHub tracker and Anthropic's disclosure dashboard. Some of his conclusions hold up. Several of his numbers mean something other than what he takes them to mean.

The full curl batch

All 45 reports are now public. Stenberg filed them as issues between November 5 and November 9, each opening with "Issue forwarded from Anthropic's OSS Scanner", an ANT-2026 identifier, the model's own severity rating, and an attached reproducer and patch. curl started handling LOW and MEDIUM reports in the open on October 26, Stenberg explained, because "all key maintainers feel strained, overloaded and brought to the brink."

This is how curl's labels stood on November 11 (05:00 UTC), next to the severity Claude gave each report:

So the security verdict is lopsided: seven confirmed vulnerabilities out of 45, all low, and the one report the model rated medium (a pinning bypass when TLS early data, HTTP/2 and a cached session line up, #23755) was downgraded. Garrity is right that this is a long way from Glasswing's April launch line about "thousands of additional high- and critical-severity vulnerabilities."

But vuln:NONE does not mean "false report". curl's own definition is that the issue has no security risk, or too little to rate LOW, and "is treated as just a bug." The tracker shows what happened to them. Searching curl's commits since November 4, we found fixes for 18 of the 45 issues, 17 of them citing "Anthropic's OSS Scanner" in the commit message: 15 vuln:NONE, 2 vuln:LOW and the one still marked ASSESS. They include a use-after-free in the cookie code when a debug callback queries CURLINFO_COOKIELIST (#23845), unbounded memory growth in the OpenLDAP backend (#23854) and HTTP/2 server push sending credentials and cookies on a redirect (#23818), all three rated NONE. Only two of the 45 carry curl's not-a-curl-bug label.

Read as security reports, the batch is mostly noise. Read as bug reports with reproducers and patches attached, it is a decent haul for four days: 18 of 45, or 40%, already fixed, with 19 NONE issues still open. Both readings are true. Calling the 19 rejections "false positives" mixes them up, and the 55.9% figure also counts the nine reports that were still unassessed in its denominator.

What Claude actually claimed

The curl batch also complicates the severity-inflation argument. In September Garrity found that Claude rated 91.5% of revealed ledger findings critical or high, against 51.3% for maintainers. Here, Claude itself rated 44 of 45 reports low. The gap in this batch is between "low" and "none", which is the line Stenberg has said he will hold harder against AI-found "crazy combos" of options that "aren't likely to ever be used in the real world."

The dashboard numbers

The more serious problems are in how the article reads Anthropic's dashboard, last updated November 2.

37,966 is not the number of reported findings. Garrity writes "of Anthropic's 37,966 reported findings, only 7,349 (19.4%) have been made public". On the dashboard, 37,966 is the count of candidates, which Anthropic's glossary defines as "every distinct crash or vulnerability hypothesis that Claude produced across the program, before any triage." Reported to maintainers: 5,087. Patched upstream, to Anthropic's knowledge: 629. That is a different figure from the 217 fixed entries Garrity counts in the ledger; the ledger reveals a finding's details only once its disclosure window has closed, which may explain the gap.

Duplicates are Anthropic's own. Garrity reads the jump in duplicates from 2 to more than 1,600 as "exactly what I warned about": other people finding and fixing the bugs first. The dashboard's glossary says a ledger duplicate is a finding Anthropic "later found [...] was the same bug as another of our findings", and explicitly "not" an entry withdrawn for duplicating a known issue. The jump looks like internal deduplication of Claude's own output. (The article itself gives the count as 1,654 in its takeaways and 1,670 in its table.)

The 94.2% has a narrow denominator. Garrity finds it odd that the true-positive rate rose while duplicates and withdrawals grew. By Anthropic's definition the rate is "the share of firm-reviewed findings confirmed as real, including duplicates and 'won't fix' findings": 6,009 of the 6,376 candidates that one of six outside firms, Trail of Bits and Doyensec among them, reviewed. Duplicates count as true positives by design. And it says nothing about OSS Scanner, whose reports Anthropic describes as "fully model-generated, without human review or triage." Comparing curl's batch with 94.2% compares two different pipelines.

Where the criticism lands

That last point cuts both ways, and here Garrity has a point he doesn't quite make. The dashboard's headline, "we've disclosed 5,087 vulnerabilities across 680 open source projects", is the sum of 1,862 findings reported after firm review and 3,225 "reported direct to maintainers by Anthropic", which the flowchart itself labels "May contain false positives." Close to two-thirds of the headline number is unreviewed model output of the same kind as curl's batch, where 7 of 45 turned out to be vulnerabilities. The 629 patches are against all 5,087.

The experience also varies by project. In Anthropic's OSS Scanner launch post wolfSSL's Todd Ouska says "of the 74 reports we received, all but two were valid, and five became CVEs", and Stenberg himself credited an earlier scan with "one of the worst curl vulnerabilities reported in the last few years." One batch of 45 is not a rate for the whole program.

Garrity's other figures we could not check independently: the 442 CVEs in his own tracking repo, and his KEV finding that two of them (CVE-2026-61500 and CVE-2026-26980) have been exploited in the wild.

What the curl tracker does show is the cost he describes. According to Garrity, Stenberg moved the reports to GitHub at a deliberate pace "to soften the impact for the team", and someone had to sort 37 non-vulnerabilities and one open question from 7 low ones. At least 15 of those 37 were real bugs worth fixing, which is the part neither side's headline number captures: a scanner that is wrong about severity most of the time can still be right about the code.