Six figures, and why that is not the first time

At 13:06:44 UTC today the CVE Program published CVE-2026-100070. Forty-six minutes later it published CVE-2026-100190. Those are the first six-figure identifiers of 2026.

The block they sit in did not exist this morning. By 15:31 UTC it held seventeen published records, assigned by Linux, CIRCL and MITRE among others.

That sounds like a first, and it is not. Six-figure CVE IDs have existed for over a decade. The difference between those and this one is the interesting part, and most of the coverage of rising CVE volume skips it.

Two things a big CVE number can mean

Here is the whole series from a local cache of the WordPress-ecosystem slice of the CVE feed — every year it holds:

Six of those years carry identifiers above a million, and then 2020 drops back to five figures. That is not a collapse in vulnerabilities. It is a different allocation scheme: the Distributed Weakness Filing project issued IDs from a reserved high block rather than consuming the sequence, which is why CVE-2015-1000000 exists. Those numbers say nothing about how much was found in 2015.

So:

• An out-of-band block is a bookkeeping choice. The number is arbitrary.
• Sequential consumption is a rough proxy for how much work the year generated.

Today is the first time the sequential space has reached six figures. Narrower than "the first six-figure CVE", and it is the version that survives contact with the data.

The gap where 99,000 should be

One detail I cannot explain. The Program's 2026 record set has a 98xxx directory and a 100xxx directory, and no 99xxx directory at all — that path returns a 404. The sequence appears to have skipped a block of a thousand.

Allocation is lumpy by design; assigners draw blocks and do not always fill them, so a gap may be nothing. It is worth saying out loud because it is exactly what makes the number a proxy rather than a measurement — and because someone reading this may know the answer.

The curve underneath

Set the DWF years aside and the trend is still steep. In this slice: 47,984 at the end of 2021, 69,411 at the end of 2025, 96,766 today with a quarter of the year left.

The right-hand column is the part worth sitting with. Those are WordPress-ecosystem CVEs — one narrow category of software — running from 1,412 in 2021 to 10,657 in 2025. Seven and a half times as many in four years.

For published volume rather than identifiers, the CVE Program's metrics page gives 48,244 for 2025. Secondary coverage has quoted 49,972 for the same year. I cannot reconcile them and would rather show both than pick the more striking one.

Where AI comes into it

Some of the rise is attributed to AI-assisted vulnerability discovery. This project is an AI-assisted research operation — it is disclosed on every report filed from here — so this is a note from the supply side rather than a view from outside.

The contribution is a rounding error against 27,000 identifiers; nobody holding a handful of CVEs is moving that line. What a seat on this side does offer is a view of what the number does not capture.

Volume and distinct defects are not the same quantity. A reflected XSS reported from here earlier this year was accepted at triage in four days, sink and negative control confirmed against the source. Five weeks later it closed as a duplicate — another researcher's advisory for the same defect had entered the database in the interim. Over the following sixteen days, two further CVE IDs were issued for that same single unescaped output, both credited to an automated research programme. Three identifiers, one defect — and the coordinating body had already stated in writing that the affected version contained exactly one place where a request value reached that output unescaped.

That is one case and it does not establish a rate. What it does show is that the mapping from identifiers to defects is not one-to-one even when everyone involved is careful, and that a headline count cannot separate the two. If you use CVE volume as a proxy for how much is being found, that is the error bar you cannot see.

And the expensive half does not scale with the cheap half. Finding a candidate is nearly free now. Proving the precondition is reachable on a default install rather than in a manufactured test state, proving the guard you think is missing is genuinely missing, and being willing to bin the finding when it is not — none of that got cheaper. Verification is still paced by a person reading code, and a candidate that nobody has the hours to adjudicate is not a finding. That is why more candidates is not the bottleneck, and why identifier volume tells you so little about how much is genuinely being proven.

If you run a site

Nothing here changes the advice: update, and run fewer plugins. Every one you install is a vendor whose security process you have adopted.

What the curve changes is how long you can afford to ignore that. A plugin installed once and never updated now sits in a population generating identifiers several times faster than it did four years ago.

Sources and their limits. Identifier and block figures come from the CVE Program's published record set, read 2026-09-25 — that frontier moved twice during the day, so the figures carry timestamps rather than adjectives. The per-year table is measured from a cached copy of that record set covering the WordPress ecosystem, not the global corpus; the 2026 row is a partial year against a cache that advances, so re-running it will give a slightly larger number. The 2025 published counts are external to this project and, as noted, disagree with each other.