37,966 AI Findings, 217 Fixes? Where Patching Stalls and Where It Keeps Up

What this is about

These days, almost every story about AI security research comes with an impressive count of findings. What happens next is more interesting. A vulnerability that has been found protects nobody until someone has checked it, understood it and fixed it. In the first half of November 2026, several data points appeared that don't seem to fit together at first glance. Security firm VulnCheck calculates that Anthropic's Project Glasswing can point to almost 38,000 findings but only 217 fixes. In the same week, the Linux kernel reported a turnaround in one subsystem, and Apache patched a critical vulnerability in 16 days.

Our thesis: the bottleneck isn't finding bugs. It's sorting through them (what security people call triage) and fixing them. If you ship reviewed patches along with your reports, or fix things yourself with AI, you keep pace. If you send large volumes of raw reports to thinly staffed projects, the pile keeps growing. On top of that, everyone counts “fixed” differently.

217 or 629: two numbers from the same company

Glasswing launched in April 2026. Through the program, Anthropic gives partners and open-source projects access to its Claude Mythos Preview model. The company publishes two data sources. The ledger is a public list in which each finding initially appears only as a cryptographic fingerprint (a hash). The project, bug type and identifiers only become visible once the disclosure grace period has expired. The dashboard, by contrast, shows aggregate totals.

According to the dashboard, “patched upstream” means the project has released a fix. It says nothing about whether users have installed it. An analysis by cellcog.ai found that all 217 “fixed” entries are among the just 235 findings whose details have already been disclosed. In other words, most of the 629 patches simply don't show up in the ledger yet.

That changes the picture considerably. VulnCheck stresses that the ledger shows only 15 new fixes between September and November. On the dashboard, over a similar period, the figure rose from 421 (early September, as cited by VulnCheck itself) to 516 (October 2) to 629. By our math, that means 1.7 percent of all candidates have been patched, and 12.4 percent of the findings actually reported. That's more than “under 0.5 percent,” but still not much.

One inconsistency Anthropic hasn't explained: on October 2, the dashboard showed 6,157 reported findings, 4,824 of them sent directly. A month later, those numbers are down to 5,087 and 3,225. A figure that should only ever go up has dropped by more than 1,000. The obvious explanation is that duplicates were removed after the fact. Anthropic has acknowledged that many reports duplicated its own earlier findings. But that link hasn't been confirmed.

What VulnCheck measures and what it doesn't

Patrick Garrity of VulnCheck has been tracking Glasswing since April and published his seven-month audit on November 9. His key points:

• 442 CVEs (public identifiers for security vulnerabilities) trace back to Anthropic. That's about 0.5 percent of all 93,450 CVEs issued this year.
• Only 2 of them are listed in VulnCheck KEV, the catalog of vulnerabilities known to be exploited by attackers.
• 1,654 duplicates compare with 217 fixes, roughly 7.6 times as many.
• The 94.2 percent hit rate doesn't account for duplicates or withdrawn findings (419).

“I don't know how to read these numbers as anything other than damning.”

The criticism lands, but it has weak spots. VulnCheck doesn't mention the dashboard's 629 at all. Its own table lists 1,670 duplicates, while the text says 1,654. The ledger's status breakdown adds up with 1,654 (4,866 + 1,654 + 419 + 217 + 193 = 7,349). Then there's the messenger: VulnCheck sells vulnerability and exploit data. Both of its Glasswing analyses end with a call to book a product demo, as the Chinese outlet QbitAI also points out. That doesn't make the numbers wrong. But the message “raw findings don't help much, prioritized data does” is also VulnCheck's business model. Infosecurity Magazine had not received a response from Anthropic by press time.

curl: almost no false alarms, but little security relevance

curl, the command-line data transfer tool, gets cited a lot. According to VulnCheck, of 34 publicly assessed Anthropic reports, 19 were “not a vulnerability” (55.9%) and 6 were low-severity vulnerabilities. In many places, that became “56 percent false positives.” That's not accurate. In curl's process, the classification vuln:NONE means “just a bug”: a real defect, but not a security vulnerability.

On November 10, Daniel Stenberg wrote on Mastodon that of the 45 findings, 7 were confirmed as LOW, 37 were “just a bug” and one was “completely wrong.” So false alarms made up just over 2 percent of cases. The real problem is different: the AI struggles to tell where a bug ends and a vulnerability begins. Stenberg said exactly that back in October. Since the spring, he wrote, junk reports have “practically disappeared,” and the new challenge is “high volume, high quality.”

curl responded by changing its process. Since October 26, low- and medium-severity reports have been discussed publicly on GitHub so the community can help review them. And in October, Anthropic did find a serious bug: a use-after-free in HTTP/2 uploads, rated HIGH and fixed in curl 8.23.0. So at curl, fixing hasn't stalled. Instead, volunteers are sifting through a large number of real but not very urgent bugs.

Where fixing keeps up: the kernel, Apache, Microsoft

Linux kernel. In May, Linus Torvalds called the security mailing list “almost entirely unmanageable” because of AI reports. The kernel responded with new rules: AI findings generally go directly and publicly to the responsible maintainers, with a concise description and a verified reproducer. During the 7.4 merge window, Torvalds said, AI was increasingly proposing the patches too, though they were often rewritten. On November 8, with 7.4-rc2, he passed on the assessment of BPF maintainer Alexei Starovoitov: in BPF, fixes are “now coming in faster than new reports.” Torvalds cautioned that most other areas aren't there yet and added: “Don't hold your breath.” There are no numbers to back this up. According to Xenospectrum, the associated merge log also notes that fixes for sockmap, a part of BPF, are still pending.

Microsoft MDASH. Microsoft's FORGE Lab scanned parts of the kernel with its MDASH system. Out of 26,502 raw findings came 59 public reports. Each came with a patch, as the kernel expects: AI agents wrote the first draft, and humans reviewed and revised it. 38 fixes have landed in mainline, a median of 41 days after the first public patch, and 108 days at most. The cost: more than four person-months for 59 reports. Microsoft itself writes that finding and fixing are “drastically out of balance.”

Apache. On October 26, Anthropic's OSS Scanner reported a critical vulnerability in the Apache web server's HTTP/2 module (CVE-2026-119618) that lets attackers execute code. The fix shipped on November 11 in version 2.4.71, 16 days later. According to Apache's security page, it's the first critical rating since October 2021. Also notable: two Google researchers independently reported the same bug on November 3. Nowhere does it say whether Anthropic included a patch. According to Socket, though, the OSS Scanner attaches suggested patches “when available.”

SoftBank: when the pile is in your own house

SoftBank CEO Junichi Miyakawa describes a special case. In June, an OpenAI model found 10,500 vulnerabilities across roughly 700 of the company's own systems, and all of them were closed in about three months. After that, GPT-6 Astra found 35,000 more. Here the company owns the code, and finding and patching run largely automatically. Miyakawa names human review as the bottleneck: checking whether interconnected systems still work together after a patch. “Frankly, we're completely exhausted.” He gave no details on the severity of the 35,000 findings.

Our take

Our assessment: the headline “37,966 findings, 217 fixes” mostly describes a measurement gap, not the whole picture. Depending on how you count, the rate is somewhere between 0.6 and 12.4 percent. So the right question is where fixing gets stuck. The counterexamples have one thing in common: either the reporter delivers reviewed work along with the report, or the maintainers have their own capacity and clear rules. That's the case with Microsoft's kernel patches, the BPF team and the fast Apache fix. Where lots of unreviewed reports pour in, the review work shifts to the projects. That holds even though maintainers requested these reports from the OSS Scanner themselves. The result: curl's 37 “just bugs” and more than 1,600 duplicates.

Plenty of questions remain. The BPF turnaround is one person's claim without data. Anthropic's shrinking report count is unexplained. No patch counter tells you whether fixes actually reach real machines. And even the loudest critic makes money from the criticism. For users, the lesson is simple: install your updates, because that's where it's decided whether an AI finding ends up doing any good.