VulnCheck’s Patrick Garrity published his third look at Anthropic’s Project Glasswing on 9 November, and it was on Hacker News’s front page the next day. The headline is “Glasswing Overwhelms Maintainers with Underwhelming Findings”, and the conclusion is blunt: “I don’t know how anyone can read these numbers as anything but damning.”
The numbers come from two places anyone can check. One is Anthropic’s coordinated disclosure dashboard, whose full data sits in a public payload.json, last updated 2 November, with archived snapshots from May, August and October. The other is curl’s GitHub issue tracker, where Daniel Stenberg has been posting a batch of Anthropic reports in public. I pulled both. Nearly every count in VulnCheck’s post matches the source. Several of the words attached to those counts don’t.
What the 94.2% is a share of
VulnCheck’s main complaint is that Anthropic’s “claimed true positive rate has risen from 90.8% to 94.2%” while duplicates and withdrawals pile up, and that curl’s experience is “a far cry” from it.
The dashboard defines the rate narrowly. It is “the share of firm-reviewed findings confirmed as real, including duplicates and ‘won’t fix’ findings.” In the 2 November data, six outside firms triaged 6,376 findings and confirmed 6,009. That ratio is 94.2%. It says nothing about the other 31,590 candidates the models produced, and nothing about the 3,225 findings Anthropic sent to maintainers with no human review at all. The dashboard labels that second group “may contain false positives.”
So a comparison with curl tells you little either way. The curl reports are labelled in every issue as “forwarded from Anthropic’s OSS Scanner,” and Anthropic’s 8 October launch post says that scanner’s output is “fully model-generated, without human review or triage” and that “it is possible reports will be incorrect or invalid.” They are a different pipeline from the one the 94.2% measures. VulnCheck is right that the rate tells a maintainer nothing about the reports now growing fastest. It is wrong to use curl as evidence that the rate itself is false.
The launch post has the one figure that does speak to scanner output. Expert reviewers checked 97 critical and high-severity scanner findings across 48 projects, and 85 of them (88%) met the bar for Anthropic’s disclosure process. That is a sample of the scanner’s most confident output, though, and the curl batch is nearly the opposite. Of the 45 reports, the scanner rated 44 low and one medium.
The duplicates are Anthropic’s own
VulnCheck reads the jump from two duplicates to 1,654 as “exactly what I warned about in September: the longer findings sit, the more likely someone else finds and fixes them first.”
Anthropic’s glossary says the opposite. A ledger entry marked duplicate means “we committed a hash for this finding and later found it was the same bug as another of our findings; the other entry carries the disclosure.” It adds that this “is not… an entry withdrawn for duplicating a known issue.” Findings that someone else had already reported are a separate category, under withdrawn. In ledger.json, 44 of the 419 withdrawn entries give “duplicate” as the reason. Of the others that give a reason, 218 are out of scope, 137 were mistakes, 11 were false positives and 5 were rejected as not security issues.
The timing fits a cleanup. Of the 1,654 duplicate entries, 1,328 were committed in August 2026. Between the 2 October and 2 November snapshots, total reported to maintainers fell from 6,157 to 5,087, and findings reported without review fell from 4,824 to 3,225. The about page explains the drop: “We found that many reported findings were duplicates of our other findings. We marked them duplicate in the ledger and stopped counting them.”
That isn’t a clean bill of health. It means the unreviewed bulk sends went out with a lot of internal repeats, and maintainers who asked for everything got the same bug more than once. Bettenburg and colleagues found in 2008 that developers often find duplicate bug reports useful, because a second report adds detail. That holds when two people describe a bug from different angles. When one model files the same bug twice, the second report mostly adds work. Still, “someone else fixed it first” is not what the data says. The cost VulnCheck should be pointing at is the repeats.
VulnCheck also flags what it calls “a bug on Anthropic’s ledger that inflates the number of findings marked as disclosed.” That one holds up. The status chips on the ledger page read 5,087 disclosed, 217 fixed, 193 pre-disclosure, 419 withdrawn and 1,654 duplicate. Those add up to 7,570 for a ledger of 7,349. The status field in ledger.json puts disclosed at 4,866.
217 fixes is the count the ledger is allowed to show
The sharpest line in the post is “In two months, Anthropic added nearly 12,000 findings and fixed just 15 more.” The table behind it compares ledger status counts of 202 and 217.
The table has two problems. First, VulnCheck’s “September 8” column is its own post date. The figures in it (26,153 findings, 2,736 entries, 202 fixed, 245 withdrawn, two duplicates, 91.4%) match Anthropic’s 26 August snapshot exactly. Second, and more important, a ledger entry only shows “fixed” once the finding is revealed. The ledger is built so that “the identifier, project, and bug class are revealed only when the disclosure window closes.” In the November data every one of the 217 fixed entries is in the revealed tier, and that tier holds 237 entries. The 217 counts fixes only among findings old enough to be public.
Anthropic’s headline count of patches is “patched upstream,” defined as “a patch has landed after the report was sent.” That number went from 421 in August to 516 in October and 629 in November, so it rose by 208 over the period in which VulnCheck counts 15. You can argue 629 out of 5,087 reported is still a poor rate, and I’d take that argument seriously. “Fixed just 15 more” mostly measures the disclosure calendar.
Not a vulnerability is not a false positive
Then curl. VulnCheck counted 34 published reports from a batch of 45: “19 have been marked as not a vulnerability, 6 have been confirmed as low severity, and 9 are still awaiting assessment. That puts the false positive rate at 55.9% so far.”
The batch is easy to find. Searching curl’s tracker for issues whose body opens “Issue forwarded from Anthropic’s OSS Scanner” returns 45, opened by Stenberg between 5 and 9 November. When I checked on 11 November, 37 carried vuln:NONE, 6 vuln:LOW and 2 vuln:ASSESS. By curl’s own verdicts it looks worse for Anthropic than it did on 9 November. Six confirmed vulnerabilities out of 43 assessed is 14%, all of them low.
The label doesn’t mean what “false positive” means, though. Stenberg described the tags on 3 November. vuln:NONE means “we deem that it has none; or it is so low that it is considered to be less than severity LOW. This issue is treated as just a bug.” A report can be a real, fixable defect and still get that label. Two weeks earlier, when he moved curl’s low and medium vulnerability handling into public view, he said he means to “deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users.”
So I checked whether the rejected reports got fixed. Curl’s commit messages cite the scanner’s report IDs. Nineteen commits on the main branch between 6 and 10 November mention an ANT-2026 identifier, and they reference 19 of the 45 issues. Fifteen of those are issues labelled vuln:NONE. One reads “gtls: enforce Extended Key Usage for server certs,” and its message says “Anthropic’s OSS Scanner issue ANT-2026-9ESFUCKT. Fixes #23763.” Issue 23763 is tagged not a vulnerability.
The static-analysis literature drew this line years ago. Ruthruff and colleagues, in 2008, separated “spurious false positive warnings” from “legitimate warnings that are not acted on,” and treated them as different problems. Curl’s 37 contain both kinds, and by the commit log at least 15 are the second. Calling all 37 false positives turns “real bug, below curl’s security bar” into “the model was wrong.” Those are different claims. The second is the one that would undercut a true positive rate.
What VulnCheck gets right
None of this makes the program look good, and some of VulnCheck’s points survive intact. The triage burden has moved to maintainers. Anthropic says so itself: it has been “bottlenecked on our human capacity to validate these findings,” and it sent “nearly 5,000 reports directly to maintainers” who asked for everything unverified. Stenberg wrote on 20 October that “all key maintainers feel strained, overloaded and brought to the brink of what we can muster.” A 2019 study of 280 Stack Overflow questions about static-analysis alerts found that the most common question was how to ignore and filter alerts, followed by how to validate false positives. Whatever a scanner’s precision, its output lands in that workflow. Curl has been through this once already this year. I wrote in September about its bug bounty closing under AI-generated reports.
The severity point holds too. Glasswing’s April launch, as VulnCheck quotes it, promised “thousands of additional high- and critical-severity vulnerabilities.” Curl received 44 lows and a medium, and confirmed six lows. VulnCheck’s count of 442 CVEs it attributes to Anthropic, two of them exploited in the wild, is its own tracking and I haven’t re-derived it. Anthropic’s dashboard lists 230 CVE records and 503 GitHub advisories across the ledger, and it doesn’t contradict that order of magnitude.
The overlap rate needs the same care. VulnCheck says duplicates are “nearly eight times the number fixed.” The two numbers come from different stages of disclosure, so the ratio means very little. The figure that would tell you whether Glasswing is mostly finding bugs others already knew about is the 44 entries withdrawn as known issues. It’s small, but it covers only what Anthropic has learned about so far.
What I’d take from it
I’d read both documents, and I wouldn’t trust either one alone. Anthropic’s dashboard publishes enough data to check, and it explains its own corrections, including the 2 November recount. Its headline rate still covers the reviewed slice of a pipeline whose unreviewed slice is now bigger. VulnCheck’s post gets most of its counts right and then attaches the most damaging reading to each one. Duplicates become other people’s fixes, revealed fixes become all fixes, and bugs below curl’s security bar become model errors.
The number I’d watch for the next update is one neither side publishes. It’s the share of unreviewed scanner reports that end in a commit, whatever severity label they get. In curl’s batch, after one week, it’s at least 19 of 45.
References
- Garrity, P. (2026). After 7-months, Glasswing Overwelms Maintainers with Underwhelming Findings. VulnCheck, 9 November 2026.
- Anthropic Frontier Red Team (2026). Anthropic’s coordinated vulnerability disclosure dashboard, overview, ledger, about and glossary and
data/payload.json, snapshot of 2 November 2026; archived snapshots of 22 May, 26 August and 2 October 2026. Accessed 11 November 2026. - Anthropic (2026). Launching an opt-in vulnerability-finding service for open-source software. 8 October 2026.
- Stenberg, D. (2026). Do minor curl vulnerabilities in the open. daniel.haxx.se, 20 October 2026.
- Stenberg, D. (2026). Scrutinize our assessments. daniel.haxx.se, 3 November 2026.
- curl project (2026). Issues forwarded from Anthropic’s OSS Scanner, opened 5 to 9 November 2026, labels as of 11 November 2026; and commits on the main branch citing
ANT-2026identifiers, 6 to 10 November 2026, including d43076108b and 293ad7d2b7. - Ruthruff, J. R., Penix, J., Morgenthaler, J. D., Elbaum, S. and Rothermel, G. (2008). Predicting accurate and actionable static analysis warnings. Proceedings of the 30th International Conference on Software Engineering, May 2008.
- Bettenburg, N., Premraj, R., Zimmermann, T. and Kim, S. (2008). Duplicate bug reports considered harmful … really?. 2008 IEEE International Conference on Software Maintenance, pp. 337-345.
- Imtiaz, N., Rahman, A., Farhana, E. and Williams, L. (2019). Challenges with Responding to Static Analysis Tool Alerts. 2019 IEEE/ACM 16th International Conference on Mining Software Repositories, May 2019.