I’ve been writing a lot this year about how AI has industrialized vulnerability discovery.
The frontier labs have spent the better part of 2026 proving it, with Anthropic’s Project Glasswing and the OpenAI-backed Patch the Planet effort from Trail of Bits turning models loose on the open source software the world runs on, and surfacing bugs by the tens of thousands.
That said, both efforts now have several months of public data behind them, and the data tells a story I have been writing about since I first covered the “Vulnpocalypse” back in April. Only a small fraction of what the models find is getting reported, and a smaller fraction still is getting fixed.
Finding was never the hard part, fixing is.
In this article, I will walk through the numbers from both programs, lean on my friend Patrick Garrity’s recent VulnCheck analysis of the Glasswing ledger, and make the case that what we’re watching play out in open source is a microcosm of what enterprises are about to face as FIRST projects 66,000+ CVEs this year.
So, let’s get into it.
The Glasswing Receipts
For those unfamiliar, Project Glasswing launched on April 7, 2026, bringing together Anthropic, AWS, Apple, Google, Microsoft, the Linux Foundation, and a number of other large vendors, along with 40+ additional organizations, to point Claude Mythos Preview at critical software, backed by $100M in model usage credits and direct funding to Alpha-Omega, OpenSSF, and the Apache Software Foundation.
Anthropic has said the model found thousands of high-severity vulnerabilities, including some in every major operating system and web browser, with examples like a 27-year-old flaw in OpenBSD and a 16-year-old vulnerability in FFmpeg.
Five months in, my friend Patrick Garrity of VulnCheck went and did what somebody needed to do, which is reconcile Anthropic’s public dashboard against its disclosure ledger, CVE ledger, and GHSA ledger. His piece, “The Anthropic Glasswing Receipts Are Starting to Trickle In”, is an excellent blog on the program, analyzing claims with real world data.
Below is an image from the Anthropic Glasswing initial update blog:
The headline figures are:
Glasswing has discovered 26,153 findings
Of those, 2,736 (10.5%) appear in the disclosure ledger at all
2,096 (8%) have been disclosed to maintainers
245 (0.9%) were withdrawn
191 (0.7%) sit in pre-disclosure
202 have been fixed
That last number is 0.8% of everything the model found, that’s what has actually been verified and fixed thus far.
Those 202 fixes are spread across 113 unique projects, which works out to an average of 1.79 fixed findings per project. Garrity also found 18 vulnerabilities that had already been patched before Anthropic reported them, and a gap between the dashboard’s claim of 421 findings fixed upstream and the 202 the ledger actually supports.
The advisory counts don’t line up either, with 82 CVEs in the main ledger versus 70 in the CVE ledger, and 77 GHSAs versus 49. As Patrick put it:
“The receipts are starting to trickle in, they just don’t reconcile.”
Now, to be fair to Anthropic, they have been candid about why. Their own language states that:
“The number of vulnerabilities we’ve disclosed is a subset of the total number of vulnerabilities that Mythos Preview (and other Claude models) has found, since the process of independent human triage and review is the rate limiting step.”
That is the entire premise of this article in a single sentence, written by the people running the program at the frontier lab.
There is another figure from Patrick’s analysis that I think is key to call out as well.
Claude rated 91.5% of its findings as critical or high severity. The maintainers who actually looked at them rated 51.3% that way. So even among the small subset that reached a human, roughly four in ten findings the model called critical or high got downgraded by the person who understands the code.
Anyone who has ever dumped a scanner report on a development team will recognize that ratio immediately.
Patch the Planet’s Ledger
Patch the Planet is the other side of the coin and, in my view, the more interesting experiment, because it was designed around fixing from the start.
Announced on June 22, 2026 as a collaboration between Trail of Bits and OpenAI, the program pairs security engineers with open source projects for a week of dedicated review, authors the patches, and submits them upstream.
Maintainers also get six months of ChatGPT Pro and conditional access to Codex security tooling. The project list includes Python, Go, zlib, cURL, urllib3, PyPI, Sigstore, Let’s Encrypt, Ansible, aiohttp, and rsync, among others.
Trail of Bits publishes a live dashboard, and to their credit, the funnel is right there for anyone to look at. As of September 4, across 59 codebases, the program has found 1,646 issues, with 1,031 (63%) awaiting a patch, 615 (37%) with a patch authored, 400 (24%) with a patch open upstream, and 215 (13%) merged, along with 11 CVEs assigned.
This is an effort where a security engineering firm is writing the patches for the maintainers, with frontier model access, backing from OpenAI, and a week of hands-on engagement per project, and 13% of findings have made it to merged.
The discovery side has clearly worked, with 224 issues reported on a single day in early June and Trail of Bits describing GPT-5.5-Cyber building a bespoke zlib fuzzing campaign in a single day, work that once took skilled researchers weeks. The merge side is running at a fraction of that pace, because merging requires a maintainer to review, accept, test, and ship, and no amount of model capability on the reporting side changes the fact that a maintainer is a human and has 24 hours in a day.
The severity mix of what did get merged is also instructive, with only 17 (7.9%) of the 215 accepted fixes rated high and 129 of them rated low, informational, or undetermined, all consuming the same scarce review capacity a high-severity fix needs.
None of this is a knock on either program. I want to be clear about that, because it is easy to read the percentages and conclude the efforts are failing, when they aren’t.
202 fixed vulnerabilities in widely used software, some of which sat undetected for decades, and 215 merged patches into projects like zlib and cURL, are real security outcomes the community would not otherwise have.
Daniel Stenberg credited AI tooling with helping fix over 100 bugs in cURL, which I covered in the original Vulnpocalypse piece, and that was before either of these programs was fully underway.
These are incredible efforts by our nations two leading Frontier AI labs, along with support from amazing teams such as Trail of Bits. We should all hope these efforts from the labs continue, as this is critical software that runs everything from consumer goods to critical infrastructure.
My point is what the funnel reveals about where the constraint actually lives.
A Microcosm of the Enterprise
I have been making some version of this argument since April, including in “The Bottleneck Was Never Finding the Bugs” and in conversations with Casey Ellis, Jerry Gamblin, and Patrick Garrity, and Glasswing and Patch the Planet are now the best public examples of it.
Open source is where the AI discovery wave hit first because the code is public and the labs could operate at scale, and it helps demonstrate the capabilities to ensure trust by enterprises for their own usage.
Now, as that happens, every dynamic in those two funnels is and will show up inside enterprise environments too.
Let’s first consider the volume.
Jerry Gamblin and Eireann Leverett’s FIRST mid-year forecast update now projects roughly 66,000 to 68,000 CVEs for 2026, running 46.3% above their original forecast, with GitHub Security Advisories up 449% year-over-year and a 164% spike in Q1 disclosures at Mozilla that the authors attribute to Glasswing and Mythos Preview.
As I argued in “Why 70,000 CVE’s is Less Scary Than It Sounds”, the same forecast notes that actionable exploitability metrics have stayed flat, so the volume is largely 25 years of debt getting found rather than a new class of danger.
That said, flat exploitability does not mean flat work. Every one of those CVEs still lands in somebody’s scanner, gets scored, gets ticketed, and gets argued about among enterprise teams when it comes to backlogs, sprint logistics and competing priorities such as feature releases, velocity, and customer-oriented product value.
Now we can consider the triage gap. Glasswing’s severity mismatch is the exact same fight that plays out between security and engineering in every enterprise I have worked in. The scanner says critical, the developer who owns the code says it is unreachable or already mitigated, and the ticket sits in the backlog while both sides dig in.
AI does not resolve that dispute, it just multiplies the number of times it has to happen.
Then there is the ownership problem as well. In open source, the constraint is a maintainer who is often unpaid and reviewing patches on nights and weekends. In the enterprise, the constraint is a product team with a roadmap, a change advisory board, a quarterly release cadence, a legacy system nobody wants to touch, and a vendor whose patch is six months out.
Patch the Planet can hand a maintainer a finished, tested patch and still watch 63% of findings sit in “awaiting patch.” Enterprises rarely even get the finished patch, they often just get a CVE ID and a due date.
Casey Ellis made a point I covered in “Slopdemic, Not Vulnpocalypse (Yet)” that I like to refer back to:
The vulnpocalypse was already here, it just wasn’t evenly distributed.
The teams drowning in backlogs before AI showed up are the same teams now, and I wrote in June that AI is pushing the security poverty line up before it pushes it down. The Glasswing and Patch the Planet numbers are what that looks like in practice.
So what do security leaders actually do with this?
I don’t think the answer is to slow discovery down, because the attackers certainly won’t, and I don’t think it is to buy another scanner. The answer is to invest in the unglamorous parts of the pipeline that the frontier labs are now discovering the hard way.
That means triage capacity that can tell a real critical from a model’s guess at one, remediation ownership that is actually assigned and resourced rather than assumed, and procurement leverage to push vendors on patch timelines, since a growing share of enterprise exposure is in software the organization did not write (e.g. third party code).
It also means being honest about how you decide what gets a human’s attention this week, because the default answer, “start with the KEV list”, is a weaker filter than most teams assume.
As I shared recently, Empirical Security’s recent whitepaper “How to Deal with Speed” put numbers on this.
Across six years of exploitation telemetry, Empirical observed 16,116 CVEs with exploitation activity. CISA’s KEV catalog held 1,307 entries, of which 894 were corroborated by Empirical’s data, which leaves 15,222 actively exploited CVEs that never made it onto KEV. More than half of the KEV entries were last seen with exploitation activity over three years ago, and as the paper points out, a scanner fires the same alarm for those as for a flaw under attack this morning.
KEV is a good compliance baseline and a fine place to start, but as Empirical argued earlier this year in “The KEV Paradox”, treating it as the only prioritization input guarantees you miss the majority of exploited CVEs.
The more valuable move, and the one Empirical makes the case for, is prioritizing on exploitation evidence and probability rather than severity scores, and then tailoring that to your own environment, with the last piece being the most critical and also the least commonly done as a standard practice.
Their data across 500+ organizations found a 29-fold efficiency improvement from prioritizing by exploitation evidence over CVSS for the same remediation effort, which matters a great deal when your remediation effort is the fixed quantity.
The paper also draws the distinction that I think most vulnerability programs still miss, that internet-wide probability and the realized risk to a specific environment are different numbers, and the gap depends on exposure, controls, and what an organization actually runs.
A global model like EPSS tells you what attackers are doing on the internet. It does not know what is reachable in your estate, which assets carry the business, what compensating controls sit in front of them, or where a patch is itself the risky change.
Getting to a local model of exploitability, reachability, and business exposure is how you make a fixed remediation budget go further, and it is the same discipline the Glasswing maintainers were applying by hand when they downgraded four in ten of Claude’s criticals. As the whitepaper puts it, the answer is to sort better before you run.
Much of this is old advice, and AI discovery just removed the excuse that we did not know where the bugs were.
Closing Thoughts
Project Glasswing and Patch the Planet are doing important work, and the community is better off for the vulnerabilities they have surfaced and the ones they have actually closed.
That said, their own ledgers show that a frontier model with $100M in usage credits behind it can find 26,000 bugs and get 202 of them fixed in five months, and that a program built specifically around writing the patches for people still has 63% of its findings waiting on a human.
The labs have solved the part of vulnerability management the industry spent two decades pretending was the hard part.
The rest of it, the triage, the ownership, the change windows, the arguments over severity, is now the whole job, and it is coming to an enterprise near you if it hasn’t already.
Are we going to build the remediation capacity to match, or keep celebrating the size of the backlog?
The angle worth adding to the triage story is what the 89% that never gets fixed actually becomes once it's public. A finding entering the Glasswing or GHSA ledger isn't neutral information sitting there waiting for a maintainer, it's now a public list of exactly which unpatched holes exist in that project, no zero day required to find them. The scanner story you're describing cuts both ways, it tells a defender what to prioritize and an attacker exactly where most of these findings are still open. For anyone running third party code at scale, the diligence question isn't just whether the org tracks KEV, it's whether they're watching these new discovery ledgers against their own dependency tree, since disclosure without a fix is now a public map of what's still broken.
Help me understand a bit in the conclusion here:
> The labs have solved the part of vulnerability management the industry spent two decades pretending was the hard part.
What was it they solved? $100M and 202 bugs fixed is half a million dollars per bug, and according to Patrick Garrity, only one of these 202 vulnerabilities has been valuable enough for an attacker to take interest in it. Unless I'm missing something major here, $100M for one meaningful bugfix doesn't sound like solved to me.