The AI CVE Tsunami: What Happens When LLMs Start Hunting Open Source Vulnerabilities at Scale

The number that should worry every engineering leader

Here is a statistic that captures the moment we’re in. In a recent episode of the Software Leaders Uncensored podcast, HeroDevs CEO Aaron Mitchell laid out the scale of the problem with a single example. Spring — the ubiquitous Java framework that powers a huge share of enterprise back-end development — had 17 vulnerabilities reported across the entirety of 2025. In just the last two months, that same framework has seen more than 40. Same project, same maintainers, same code being scrutinized; the only thing that changed is how the scrutiny is happening.

That’s not a gradual uptick. That’s a step-change. And Spring isn’t an outlier — it’s a preview. At HeroDevs, where we maintain secured versions of hundreds of the most widely used open source libraries on the internet, we’re watching the same curve bend across the entire ecosystem at once. The frameworks change, the languages change, but the shape of the line is the same everywhere: flat for years, then suddenly vertical.

Coming into the year, the reasonable forecast was something like a 33% increase in CVEs over the prior year. That alone would have been a tough year for security teams. But with large language models — Claude, Codex, and every other coding-capable LLM — now systematically probing open source codebases for flaws, that projection looks badly low. The more realistic number is that reports could double. We may approach 100,000 CVEs reported this year, a volume that will simply break the systems and the people who triage them. The National Vulnerability Database, the maintainers, the security teams downstream — none of that infrastructure was designed for six-figure annual volume.

‍

Why AI changes the vulnerability equation

For most of open source history, finding a vulnerability required a human with deep expertise, time, and motivation to go looking. Security research was a craft. That natural friction — the sheer effort involved — kept the flow of reports at a pace maintainers could roughly absorb. It wasn’t that the bugs weren’t there; it’s that discovering them was expensive.

LLMs remove the friction. A model can read an entire library, reason about edge cases a human might take days to map, and surface plausible vulnerabilities in minutes — then do it again across thousands of projects without tiring, without context-switching costs, and without needing to be paid by the hour. The cost of looking has collapsed toward zero, and anything whose cost collapses toward zero tends to explode in volume. We have effectively industrialized the discovery half of vulnerability research while leaving the remediation half exactly as manual as it has always been.

This produces two effects pulling in opposite directions. The tailwind: more vulnerabilities surfaced means more real problems found and fixed, so in principle the software supply chain gets safer over time. Latent bugs that would have sat undiscovered for years are now being flushed out into the open. The undertow: every report — valid or not — has to be triaged, reproduced, validated, patched, and re-built by a human maintainer before anyone is actually safer. And a meaningful share of AI-surfaced reports are low-quality, duplicative, or outright wrong, which means maintainers now spend scarce hours disproving machine-generated noise on top of fixing the real issues. AI generates reports at machine speed; humans still resolve them at human speed. That gap between machine-speed reporting and human-speed remediation is the crisis.

‍

The maintainer burnout problem

Most of the open source the modern economy runs on is maintained by a startlingly small number of people. As the saying goes: plenty of engineers know how to drive the car, but the number who can actually fix it you can often count on one hand. For some of the internet’s most depended-upon libraries, the bus factor is genuinely one or two people.

Many of those maintainers do the work in their spare time, on top of a full-time job, out of a sense of stewardship for a project the world depends on. Now ask them to test and validate dozens of incoming reports a month, ship fixes, and verify that every downstream build still works against those fixes. That last step matters more than people realize: a patch that breaks the build for thousands of dependent projects isn’t a fix, it’s a new incident. So the real work per report is multiplied — diagnose, patch, regression-test, rebuild, release, and field the follow-up questions.

A growing number of maintainers are reaching the same conclusion: I can’t keep up anymore. When a maintainer burns out and walks away, the library doesn’t get safer — it goes dark. The reports keep coming; the fixes stop. For any enterprise relying on that component, an abandoned project is a liability sitting quietly in production, waiting to be the next headline. The uncomfortable truth is that the AI vulnerability surge is, in part, an attack on the volunteer labor model that the entire software industry quietly depends on.

‍

The enterprise is feeling it from both sides

BlackDuck’s annual Open Source Security and Risk Analysis has shown the amount of open source in the average commercial codebase has tripled in the last five years. The typical application now pulls in thousands of open source components — most of them transitive dependencies the team never chose directly — each with its own lifecycle, its own support window, and its own end-of-life date.

Put on an engineering manager’s hat for a second. You’re responsible for thousands of components. Every one of them has a date when it stops being supported. Tracking that across an entire portfolio, by hand, is effectively impossible — and that’s in a calm year. Now layer on a vulnerability stream that may double, and the urgency at the enterprise level is unlike anything we’ve seen: I have to get secure on all of these libraries, the reports are landing faster than my team can read them, and I have no realistic way to keep up manually. The result is a scramble — emergency patching cycles, security teams drowning in alerts, and leadership asking why a number that was manageable last year is now a board-level risk.

‍

The two ways teams get caught

In our experience, organizations get burned in one of two ways. The first is the abandoned dependency: a library deep in the stack whose maintainer has stopped responding, so when a critical CVE lands there is simply no upstream fix coming and no one in-house who understands the code well enough to write one. The second is the upgrade treadmill: a team that does have support but is so many versions behind that adopting the patched release means a painful, multi-week migration they can’t schedule on demand. Both leave you exposed in the window that matters most — the days right after a vulnerability goes public, when the exploit attempts begin.

‍

What actually works: visibility plus drop-in coverage

The old model of security was acute and local: I’m stuck on one critical library, and upgrading will take months. The new model is broad and systemic: I have thousands of libraries, each on its own clock, and I can’t wrangle any of them. Solving the new problem takes a different posture, and it comes down to two capabilities.

First, visibility. You can’t secure what you can’t see. Engineering and security leaders need a clear, continuously updated map of everything they’re running, which components are unsupported, which versions are end-of-life, and which projects have been quietly abandoned by their maintainers. That inventory is the foundation; without it, every other security investment is guesswork.

Second, coverage without a roadmap interruption. When you find an end-of-life library you depend on, the traditional answer is to halt feature work and spend months migrating. That’s a tax most teams can’t pay on demand, especially during an active vulnerability surge. A drop-in replacement — a secured, supported version of the same library that swaps in within minutes — puts the timeline back in your control. You stay patched today and migrate to the latest version when it makes sense for the business, not when an abandoned dependency forces your hand.

This is the heart of what HeroDevs does. We maintain secured versions of end-of-life open source — hundreds of the most popular libraries across the ecosystem — and back them with SLAs, so that always secure, always supported, always compliant is something an enterprise can actually achieve across its whole stack, not just its most painful single dependency. AI is also a tailwind for this work: it’s accelerating how fast our teams can stand up new projects and resolve security issues, which is part of how coverage keeps pace with demand.

‍

The honest part

Is keeping pace with this easy? No. It’s genuinely hard, and anyone claiming they’ve fully solved it is selling something. It comes down to ruthless prioritization — starting with the libraries that stand up the most critical systems — being customer-driven about what to cover next, and recruiting the rare engineers who can actually fix these projects rather than just use them. But the volume is real, it’s rising, and pretending otherwise is how organizations end up caught flat-footed.

‍

The takeaway

The AI vulnerability tsunami isn’t a forecast — it’s already here, visible in the data, and accelerating. Enterprises that treat open source as set-it-and-forget-it are accumulating risk faster than ever. The ones that will weather it are building visibility into what they run and securing coverage they don’t have to babysit. The reports are coming at machine speed. Your remediation strategy has to stop running at human speed.

 Listen to the full conversation with Aaron Mitchell on the Software Leaders Uncensored podcast.