Starting today, if you report a low or medium severity vulnerability to curl, it does not go to the security team. It goes into a public GitHub issue queue with everything else.
Daniel Stenberg announced the change on October 20. His reason is worth reading closely, because it is not the reason you would guess: “This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in.” Over the last few years, he notes, more than 90% of submissions could quickly be assessed as less than high severity.
Two days later he published something that complicates every story written about AI and open source in the last eighteen months, including mine. “Since spring 2026 the slop reports are practically gone,” he wrote. Recent months have brought hundreds of vulnerability reports and “every single one had AI involved to some extent.” His assessment of them: “I personally don’t refer to this as AI slop because the reports are typically accurate and correct, even if much too wordy.”
And then the line that should end the lazy version of this conversation: “Ignoring real vulnerabilities because they were found by AI does not make users safe and secure. It makes them vulnerable.”
So the quality problem got solved. The reports are real. And the maintainer of one of the most widely deployed pieces of software on earth just moved ninety percent of his intake onto the public commons anyway.
That is the story of October, and it is not a story about slop.
The lab hit the same wall first
On October 8, Anthropic launched a free vulnerability scanner for open-source projects. Buried in the announcement is the most candid thing a frontier lab has said this year:
“We have discovered over 29,000 candidate vulnerabilities, but have only been able to manually review and triage approximately 6,000 of these. While 6,000 vulnerabilities is significant, we remain bottlenecked on our human capacity to validate these findings.”
Read that again. The company with the model that found the bugs could not keep up with the bugs its model found.
Their resolution was to stop trying. The scanner’s reports are, in their own words on the Cyber Mission page, “model-generated and sent without human review. That means maintainers receive them faster, but it also means that some will contain inaccuracies.” The quality bar is an expectation rather than a measurement: “We expect a true-positive rate above 90%.”
The scanner FAQ contains a sentence I find genuinely admirable and also damning: they will not impose a disclosure deadline on unvalidated findings because “we do not feel comfortable forcing maintainers to carefully read each finding if we have not yet done the same.”
They know exactly what they are handing over. They said so.
The scoreboard nobody quotes
Anthropic publishes a live disclosure dashboard, which is more transparency than most of this industry offers, so the numbers below are to their credit as data even as they are the problem.
As of October 2: 29,439 candidate vulnerabilities found. Around 6,123 reviewed by external security firms. 6,157 disclosed to maintainers, of which 4,824 went out direct and unvalidated. 5,103 acknowledged.
Patched: 516.
That is 8.4% of what was disclosed, and under 2% of what was found. The dashboard is careful to note that patch counts lag, which is true and fair. It is still the clearest picture available of where the work stops.
The pattern repeats one level up. Anthropic’s Cyber Verification Program announcement on October 6 reported “at least 129,000 verified software vulnerabilities between April and July 2026” from its partners. The announcement contains no total for how many were fixed, and explains why: “fewer than 50% of partners disclosed patched numbers, often because their fixes were still in progress.”
Finding is now a volume business. Fixing is still a cottage industry.
Google just closed the door
On October 1, Google paused new product vulnerability reports to its open-source reward program, pointing to a rise in automated submissions. It is worth being precise here, because the lazy version of this story is everywhere: Google did not say those submissions were AI-generated, and gave no figures. Supply-chain reports still go through, and an update is promised in the first quarter of 2027.
curl pushed the cost onto a public queue. Anthropic pushed it onto maintainers. Google shut the intake. Three different institutions, one month, same decision.
Harvard measured the identical shape inside companies
Here is where it stops being a security story.
Fiona Chen and James Stratton of Harvard analyzed roughly 300 million work events across 718 firms and 725,938 workers, using engineering telemetry spanning January 2021 to March 2026, to measure what AI coding agents actually changed. Their paper is a job-market paper rather than a peer-reviewed publication, hosted on the author’s own site, and the data comes from Jellyfish, a vendor that sells engineering analytics to the firms in the sample. Weigh it accordingly. It is still the largest measurement of its kind that exists.
What adoption produced: “30% for lines of code, 20% for commits, and 23% for pull requests.”
What it did not produce: any detectable increase in finished work. For resolved issues the estimate was 0.12 per worker-month against a baseline of 3.67, with a standard error of 0.17, which is statistically indistinguishable from nothing. Completed epics, the same. Their confidence intervals “allow us to rule out effects larger than 12% of the baseline mean.”
Where the time went: the path from pull request to merge lengthened 49%, from about seven days to over ten. The share of pull requests with changes requested rose from 0.13 to 0.25, close to double. Comments per pull request rose 35%. The share of workers doing code review rose 14%.
Output up a third. Delivered work flat. Everybody in the review queue.
A junior engineer quoted in the paper describes the texture of it better than the regressions do: “People could make a huge number of commits quickly, but code review was still the bottleneck. He could only review my code once a week. After some outages that were caused by AI-generated commits, there were also new rules requiring senior engineer approval for AI-generated code, which created even more review bottlenecks.”
The statistic that explains everything
Of all the numbers in that paper, one stopped me.
As of March 2026, nearly 80% of firms in the sample had used AI tools somewhere in the code review process. And yet only 23.3% of review comments were AI-generated, and only 10.8% of pull requests received even one AI comment.
The tools were bought. The tools were installed. And when the actual checking had to happen, humans did roughly nine-tenths of it anyway.
That is not a capability gap. These are the same models that wrote the code and found the 29,000 vulnerabilities. It is a trust gap, and it is the whole economics of this moment compressed into two percentages. We deployed AI enthusiastically on the half of the work that produces something visible, and we quietly kept humans on the half that decides whether the visible thing is real.
What this is not
Two corrections to the story I would otherwise be tempted to tell.
This is not a safety crisis. VulnCheck found that of 1,061 vulnerabilities attributed to AI-assisted discovery, 14 had been exploited in the wild. That is 1.3%, which they note is “roughly matching the overall exploitation rate” for everything else, and they say explicitly that their data does not suggest AI-discovered vulnerabilities are more likely to be exploited. The cost here is labor, not danger. Anyone selling you danger is selling something.
This is not an argument against AI vulnerability research. It works. Models found a real high-severity flaw in curl that Stenberg shipped a fix for in October, and he has called the current generation of findings genuinely better than what traditional analyzers produced. Refusing the findings would be worse than receiving them. He said so, and he is right.
One real asymmetry does show up in the data. VulnCheck’s audit of the disclosure ledger found the model rated 91.5% of its findings critical or high, while maintainers who reviewed them rated 51.3% that way. The machine is not making things up. It is reliably more alarmed than the person who has to act.
The thing to actually watch
In September I argued that AI drove the cost of producing a claim to zero without touching the cost of checking one, and that verification had quietly become an unpaid tax. I thought the open question was who would end up paying it.
October answered: nobody pays it. It gets moved.
The lab moved it to the maintainer. The maintainer moved it to the public queue. Google moved it out of the building. Inside companies, the engineer who used to write code moved it to the senior engineer who now spends 49% longer getting a change merged. At each step the person handing it off is acting reasonably, and the cost is undiminished, and it is always someone else’s week.
So if you run anything that consumes AI output, and at this point that is everyone, the question worth asking is not what your tools can generate. It is who verifies it, whether that person agreed to, and what happens when they stop. I build and run these systems every day, and my own audit is uncomfortable reading: the generation side of my stack is instrumented and fast, and the checking side is me.
The bottleneck did not disappear when we automated production. It just stopped being visible from the side of the pipe that gets celebrated.
