- More than 23,000 vulnerabilities were identified in the first month after Anthropic's Project Glasswing, Endor Labs says; it says fewer than 5% have been fixed.
- The scarce resource is now the repair, not the discovery, and much of it rests on volunteer maintainers.
- Ask your team which flaws actually reach your code, and who owns the fix when your own tools find one.
Finding a software flaw used to be the hard part. A report from Endor Labs suggests the hard part has moved. Finding is now cheap and fast. Fixing is slow, and it often depends on people who are not paid to do it.
The lesson here is simple. Think of a city whose inspectors suddenly find far more cracks in its roads. The crews that fill the cracks have not grown. The list gets longer, not shorter. Open source is in that position today.
What the report says
Endor Labs, a software security vendor, published the figures on October 12, 2026. Its count covers the month after Anthropic announced Project Glasswing. In that time, researchers and tools surfaced upwards of 23,000 weaknesses spread across more than 1,000 open source projects.
More than 6,000 were rated high or critical. Over 90% were confirmed as real by independent security researchers. Glasswing's partners found more than 10,000 further high or critical flaws in the systems they run.
The post does not say exactly which set of flaws the 5% refers to. Treat it as a vendor's estimate, not an audited count.
Why volunteer maintainers are stretched
Endor Labs says the cause is structural, not a failure of maintainers. In its words, no volunteer ecosystem was designed for this volume of confirmed reports. The post adds that maintainers have asked Anthropic to ease the pace of its disclosures because they are overwhelmed.
The curl project shows the strain. Its code runs on an estimated 20 to 30 billion devices, according to the post. In June 2026 curl said it would stop taking vulnerability reports for July. Maintainer Daniel Stenberg wrote that four months of AI-generated reports had left the team needing rest.
That is the human cost. A small team, under steady pressure from AI-generated reports, closed its intake for a month. The post says the team did not expect the pressure to end. A pause in intake means one fewer channel for reports to reach the team.
How the proposed fix works
Endor Labs is launching Zero-Day Patches. It says it will deliver a tested fix within 24 hours of a customer reporting a new flaw, before the project has an official patch or a CVE. A CVE is the public ID given to a known vulnerability. That timing is the company's claim, and the post offers no independent check.
The method has three steps. First, it builds a call graph, a map of which code calls which. It then traces dataflow, meaning how information moves through the program. Second, it writes the smallest change that closes the hole. Third, it generates tests and exploit code, and supplies build and test logs as evidence the fix works.
The first step matters most for executives. A flaw can be real in a library yet unreachable, because your application never calls the affected function. Endor Labs says its reachability analysis ranks findings for each customer's own software. That turns a long, flat list of alerts into an ordered one.
Who owns the patch
The design choice to watch is where the fix goes. Endor Labs says its temporary patch stays in the customer's setup only until the project's own release includes the repair. It says it will not maintain a fork. It also says it routes every finding through Project Akrites, the Linux Foundation's coordinated disclosure effort, so a maintainer hears about each issue once, with the fix and logs attached.
The company says maintainers get fixes free and will not need a waitlist. It also says it will publish its upstreaming numbers. Those numbers are the test to hold it to.
Keep the vendor's position in view. Endor Labs sells this service, and the post is a launch announcement. The scale of the problem is stated by the vendor, and the solution is its product.
Questions to put to your team
Do we know which vulnerable open source functions our applications actually call? Without that, a list of thousands cannot be ranked.
When our own AI tools find a flaw in a package we depend on, who decides how we disclose it? Who writes the interim fix, and who removes it when the official release arrives?
Do our suppliers have a plan if a key maintainer pauses intake, as curl did? Is any of our open source support funded, or do we simply consume it?
Discovery is now a machine task. Repair is still a human one, and the organisations that depend on it need to plan for that.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
