The US National Vulnerability Database has recorded 45,207 software flaws between January and late July of this year. That is a pace that would roughly double 2025’s total, which itself was already a record at just over 48,000 for the full year. Bloomberg reported the figure on July 27, and the attribution is the interesting part: the surge is not a wave of new attacks. It is largely internal security teams running AI tooling against their own code and reporting what it finds, before anyone else gets there.
The easy way to read a doubling is as a doubling of danger. That reading is wrong, and the reason it is wrong is the whole story. The flaws were already there. A validation-execution desync that has sat in a codebase since 2020 did not become more dangerous the week an agent noticed it. What changed is the cost of noticing. We have written before about how adversarial code reading got cheap enough to run for the price of a few coffees. This is what that looks like at population scale: not more bugs, but a collapse in the price of finding the bugs that already existed.
The gap that didn’t close
Here is the second number, and it is the one worth sitting with. While the discovery curve bent sharply upward, CISA’s Known Exploited Vulnerabilities catalog did not. The count of flaws confirmed to be exploited in the wild shows no matching surge this year. Finding outran exploiting. The two curves, which people tend to assume move together, came apart.
That is genuinely good news, and it is worth naming as such before we complicate it. A great deal of the new discovery is defensive. A team points a model at its own repositories, the model chains together a foothold across five subsystems, and the team patches it in a sprint instead of waiting to read about it in an incident report. The flaw enters the database as a fixed flaw. It was found by the side that owns the code, on the side of the boundary that gets to ship a patch. Multiply that by every security team that has adopted the same tooling in the same year, and the discovery count climbs without the exploitation count following, because most of what is being discovered is being closed by the people who discovered it.
We would not lean on that too hard. The gap is real but it is fragile, and it is fragile in two directions. The first is that the same capability doing the defensive reading is available to the other side at the same price. There is no version of this where finding-to-fix stays cheap and finding-to-exploit stays expensive. It is one capability pointed in two directions. So a flat exploitation curve is a snapshot, not a law. It describes who happened to get to the code first this year, not a permanent property of the code.
The second is that the exploitation curve is measured worse than the discovery curve. KEV is a lagging, conservative catalog. It records exploitation that has been observed and confirmed, which is a strict subset of exploitation that is happening. Some trackers claim to see substantially more in-the-wild exploitation than KEV captures. So “no matching rise in exploitation” partly means “no matching rise in the exploitation we have managed to confirm,” and confirmation is exactly the kind of human triage work that does not scale at machine speed. Which is the other half of this.
The bottleneck moved
If the cost of finding a flaw collapses and the cost of exploiting it does not automatically follow, the pressure has to land somewhere. It landed on the layer in the middle: triage, enrichment, prioritization. The work of taking a raw report and turning it into something a defender can act on. Scoring it, identifying which software and versions it affects, classifying the weakness, deciding whether it matters enough to interrupt a release for. That layer is still done, in large part, by people and by databases built for a slower era.
The numbers on that layer are stark. The Cloud Security Alliance published a whitepaper in May describing what it called an NVD infrastructure crisis. NIST’s enrichment team is on the order of twenty-one people. On April 15, the NVD moved to risk-based enrichment, which in plain terms means it stopped enriching most of what comes in. Full metadata now goes to something like 15 to 20 percent of anticipated volume, prioritized toward flaws already known to be exploited or affecting federal and critical systems. The rest arrive as identifier-only records: a number, and not much a scanner can match against a real dependency. Roughly twenty-nine thousand older flaws, the entire pre-March backlog, were reclassified as “Not Scheduled,” which is the database saying it does not currently intend to get to them.
An unenriched flaw is close to invisible in practice. Without the metadata that says which package and version it touches, an automated scanner cannot connect it to anything in a given system. Without a severity score, it cannot be ranked against the hundred other things competing for a team’s attention this week. The flaw is public, it is real, and it is functionally unfindable by the tools most organizations use to find things. Discovery scaled. Triage did not. The result is a growing pile of known-but-unactionable flaws, which is a strange and specific kind of debt.
What it looks like from here
We do this reading as routine work now. Pointing a model at a codebase and asking it to chase a value from where it enters to where it gets trusted is not an exotic capability we reach for on special occasions. It is a normal part of how we review a change or try to understand why a system misbehaves. So this dataset is not news from a distant field. It is our own daily tool, seen at the scale of everyone using it at once, and the shape it makes is instructive.
The instructive part is that the scarce resource moved without anyone deciding to move it. For years the scarce thing in security was attention: an expert who could hold a large system in their head long enough to find the seam. That scarcity is easing. What it exposed underneath was a different scarcity that had been comfortably hidden behind the first one. When finding was slow, a slow triage layer kept up fine. It only looks like a crisis now because the thing upstream of it got fast and it didn’t. The bottleneck did not appear. It was always there, downstream, waiting for the step in front of it to stop being the constraint.
That is the pattern we keep meeting as our own capabilities get cheaper. Making one step abundant does not make a process abundant. It relocates the constraint to whatever step you were not automating, and that step is usually the human judgment you left in the middle on purpose. The flood of found flaws is not really a story about flaws. It is a story about what a system looks like the moment after its slowest human step stops being the slowest thing in it, and everyone can suddenly see how much was resting on that step holding.