2026 has already published twice as many CVEs as 2025

The count, as of this morning#

I keep a rough sense of how many CVEs a year produces, because patch queues, Cyber Essentials evidence, and every "is this critical?" conversation sit on top of it. The sense I had in January is already wrong.

On the morning of 15 November 2026, a count of published CVEs by publication date, with rejected records left out, stood at 97,739 for 2026. On the same date in 2025 that count was 41,430. The whole of 2025, in the same series, finished at 48,150. 2026 is already just over twice last year's full total, with six weeks still to go, and it is running at about 2.4 times the same point last year. The tracker that published those figures rebuilt them at 10:35 GMT today.

Two days earlier, The Register reported that VulnCheck's count had passed 100,222 at about 16:00 GMT on 13 November, more than double 2025. Josh Bressers, VulnCheck's director of coordinated vulnerability disclosure, told them the part I think is the actual story: vulnerability hunting with AI is driving a majority of what they are seeing, and in a couple of years 100,000 will sound small.

Those two numbers do not match, and they should not be forced to. One database drops rejected records and waits until a CVE is actually published. Another counts what it has ingested by a given hour. The CVE Program's own metrics page is stricter again. It reconciles each quarter after the quarter ends, removes records that were later rejected, and has not closed the fourth quarter of 2026. On those books, 2026 through 30 September is 72,812 published records, against 48,244 for the whole of 2025. That is already 1.5 times last year's full year, before October and November are folded in.

Pick a counter. The shape is the same. Disclosure went vertical.

What the years before this one looked like#

The CVE Program's published-record totals, reconciled at year end, are the cleanest long series. 2026 in this table is only the first three quarters.

Before 2017, a busy year was a different sport. From the middle of the 2000s through 2016, the annual published total usually sat between about 4,000 and 8,000. 2005 was 6,708. 2011 was 4,150. 2014 was 7,948. 2016 was 6,457, about 18 records a day.

2017 more than doubled that, to 14,645. The programme was growing up. More vendors and researchers became CVE Numbering Authorities and published their own records, instead of everything funneling through a last-resort root. In 2017 that split was about half and half. In 2025, numbering authorities published 89% of records and the last-resort roots published 11%. In 2026 so far the split is 95% and 5%. The programme now lists 567 numbering authorities.

That structural change explains a lot of the climb from 2017 to 2025. The line was already steep. 2023 was 28,961. 2024 was 40,077. 2025 was 48,244, about 132 a day, a bit more than seven times 2016. A claim that "AI invented the vulnerability boom in 2026" skips a decade in which the programme got bigger and there was simply more software to number.

The quarters are where 2026 stops looking like that previous slope.

2025 was almost flat: roughly 12,000 records a quarter, all year. 2026 opened at 15,154, which was busy and still recognisable. The second quarter was 20,696. The third quarter was 36,962.

One quarter of 2026 published almost as many CVEs as the whole of 2024, and more than the whole of 2023. It was about three times the third quarter of 2025. That is about 400 published records a day, against about 132 a day across 2025.

Google's Threat Intelligence Group, counting disclosures through 31 August, saw the same bend inside the year: 5,045 vulnerabilities disclosed in January 2026, 10,477 in July, 10,740 in August. Their write-up is worth reading beside the official totals, because they also show how much of the raw count is noise. Records whose description contained "Linux kernel" alone came to about 5,000 CVEs between January and August, and they observed no exploited zero-days in that set.

A single week can now sit next to an old year. In the week of 12 to 18 October, one count recorded 5,460 CVEs. The CVE Program's reconciled total for the whole of 2016 is 6,457. That tracker's 12-week average sat at 3,247 unique vulnerabilities a week. A year earlier the same average was 924. From January 2020 to November 2022 it was 427.

The pile is disclosures, and several things are in it#

A published CVE is a disclosure. Someone found something, wrote it up, and a numbering authority agreed it was a vulnerability in a product they cover. It is a weak stand-in for "how broken is all software this year."

Four things are stacked in the 2026 pile.

More of the world's bugs are being written down. 567 numbering authorities, bulk publication in huge open-source projects, and a reserved-ID pipeline that is already past last year. The programme has reserved 105,782 CVE IDs in 2026, against 70,729 reserved in all of 2025. A reserved ID is a placeholder. Many are still under embargo. Some are never published. The pipeline is full, and it is a larger pipeline than last year's entire reservation book.

AI is hunting. This is the part that changed the slope. Bressers was blunt with The Register. Vulnerability hunting with AI is driving a majority of what VulnCheck is seeing, and the major numbering authorities are "screaming into the atmosphere." Microsoft alone added 1,094 flaws on 10 November, after 1,474 the month before. A model can read a codebase, a patch diff, or a firmware image for longer than a person can, and it can be pointed at products that never had a research team.

There is a new estate to hunt: the AI stack itself. That pile is real, and it is the smaller one. More on it below.

A lot of the new records will never be the one that ruins a week. Severity, in the publication-date series, as of this morning:

High has already more than doubled the whole of last year. Critical is up sharply and has not doubled yet. The unscored pile is much fatter than it used to be: 3,225 records still had no score that morning, against 897 across all of 2025. A dashboard that only counts critical is a blunt instrument when thousands of records have no score yet.

Google's team tried to separate an AI-found subset from the rest, for January to August, using lab disclosures and advisories that actually credit a model or an agent. Public data undercounts this. There is no required "found by AI" field, and a cloud provider will often patch a finding inside its own service without ever requesting a CVE.

In the set they could identify, the mix differs from the firehose. On their threat-risk rating, conventional disclosures were 69% low and 28% medium. The AI-discovered set was 39% low and 58% medium. Half of the AI-discovered vulnerabilities led to remote code execution, against 26% across the wider CVE set. Researchers are aiming the agents at privilege boundaries and code execution, which is what you would expect, and the output matches the aim.

Treat that mix as a described subset, and the share of the whole pile as uncounted. Another tracker, with data through 18 October, found only 218 CVEs in 2026 that say outright they were found with AI help, 51 of them in September, and none at the same point in 2025. There is no field on a CVE record that says who, or what, did the finding. Bressers' "majority" is what the intake looks like to a numbering authority. I believe that reading. The published statistics do not contain another change that triples a quarter on its own. The records themselves still will not show you the share.

The new software has its own holes#

AI is doing the hunting. It is also a new estate, and that estate is collecting CVEs of its own.

Google's group tracked 2,076 AI-related CVE disclosures from January 2025 through August 2026, and more than 1,500 of those fell in 2026. Agent orchestration frameworks, the Langflow, Flowise, and LangChain class of tools, accounted for 782 of the 2026 slice. Inference servers and gateways, the vLLM and Ollama class, accounted for 212, and about a quarter of those were unauthenticated APIs or server-side request forgery. Confirmed exploitation of that middleware in the wild was still a handful of cases.

A keyword count through September put vulnerabilities that merely mention AI at 532 in that month, up from 104 a year earlier, and at about 3.6% of everything reported over the prior twelve months. Most of those are flaws in LLM apps and agent tooling.

The AI-product pile is a few thousand records. The annual total is close to 100,000. Discovery against software the world already runs, plus a decade of growth in who is allowed to publish a CVE, is what moved the year.

Exploitation grew, on a much smaller base, and the clock shrank#

CISA's Known Exploited Vulnerabilities catalogue added 297 entries in 2026 by this morning, against 221 on the same date in 2025, and against 245 in the whole of 2025. That is about 34% up on the same date. Those are catalogue admissions during 2026, whatever year the CVE was published, and the year is already past the full-year totals for 2023, 2024, and 2025. It is a long way from double.

The clock on those additions tightened. The median time from an NVD publication to a KEV entry was 26 days in 2025 and 12 days so far in 2026. Sixty percent of this year's additions arrived within 30 days of publication, against 51% last year.

Google, on a different exploited-in-the-wild set and only through August, counted 141 vulnerabilities disclosed and exploited in their 2026 window, already past the 127 they recorded for all of 2025. The monthly average moved from 10.5 in 2025 to 18. In that sample, about 0.23% of 2026 disclosures were observed exploited, roughly one in 431. Zero-days moved less than the n-day pile: about 8 a month in 2025, about 11 a month through August 2026, with August itself at 22. Their reading is that attackers are getting more mileage from reading the patch than from stockpiling secret bugs, and that models are good at that reading.

VulnCheck's known-exploited catalogue is larger than CISA's. It held 1,363 of this year's CVEs at the time of the Register interview, about 1.4%. The percentage can hold still while the workload explodes. One percent of a thousand and one percent of a hundred thousand are different jobs.

The speed stories match the medians. VulnCheck's median time from publication to exploitation fell from 120 days in 2025 to 80 days in the first half of 2026, and they said the second half has been shorter still. CrowdStrike, for January to June, said 88% of the exploitation they observed that used a public proof of concept landed within 48 hours of that proof of concept. On 13 November, VulnCheck published 14 local root flaws in Copeland refrigeration controllers, two of them already exploited, and saw hits on their honeypots within minutes.

An interesting bug is being tried while the advisory is still warm. The rest of the pile is not showing up in those exploited catalogues.

What I would actually do with this#

A flat list of everything that scored 7.0 this week is no longer a plan. Bressers' line is the right one: "We don't have a security problem anymore. We have a data problem now."

The useful sort is the one CISA wrote into BOD 26-04 on 10 June 2026, for US federal civilian agencies. It is US federal policy. The model is the clearest public statement of how to triage once volume breaks a severity-only queue. Four questions, asked per asset:

1. Is it publicly exposed?
2. Is this CVE on the Known Exploited Vulnerabilities catalogue?
3. Can an adversary automate the exploit?
4. Does success give partial control, or total control?

The directive retires a single CVSS deadline for everything internet-facing. For an internet-facing asset, a known-exploited bug that an adversary can automate sits on a three-day clock. Where success would give total control, that clock includes a forensic check of the asset, including some cases where the exploit is not automatable. Some low-risk cases are allowed to wait for the next planned upgrade. The directive names that as its own timeline. Cybersecurity Dive's account of the grid is the readable version of the figure on CISA's page.

For a UK business, the rule an assessor will actually test is narrower. Cyber Essentials, after the April 2026 update, auto-fails if a critical or high-risk fix, a fix at CVSS 7.0 or higher, or an unscored fix has been available for more than 14 days on in-scope software. That condition is about products you run. The work is knowing the estate well enough that the 14-day list is short.

The order I would want on a Monday:

1. Internet-facing kit you actually have, matched to the KEV and to whatever your own telemetry says is being tried. Edge appliances and security gateways keep showing up in real intrusions, because they sit in front of the EDR agent. Identity still shows up more often than a fresh zero-day. I have written about both: the grey zone, where the intrusion looks legitimate once the door is open, and ITDR, because a large share of compromise is a login that succeeded.
2. Anything with a public proof of concept on a product you expose. Treat a couple of days as the planning assumption for the interesting ones.
3. The long tail, on a slower clock, grouped by product and by whether a vendor fix exists. A critical in a library you do not ship, on a subnet nothing can reach, can wait its turn.
4. If you maintain open source, protect the humans reading the reports. curl's maintainer, Daniel Stenberg, shut the project's bug bounty this year after AI-generated submissions buried the security team. From 26 October, low and medium reports go straight to the public tracker. High and critical stay private. If you run agents against other people's code, send a reproducible high-impact bug, and send nothing else.
5. If you build software, point the same review at your own tree first. A finding patched before release never becomes one of these 97,739. That is the better outcome.

The volume is genuinely wild. It is a reason to shorten the list, build it from exposure and exploitation, and refresh it faster than a quarterly patch meeting. It is a reason to be able to name the estate. The cost of looking fell through the floor, so the world is looking, and publishing, faster than a room of people can read.

References#

Figures above come from these pages. Counts move as records are rejected, scored, or added, so the 15 November numbers are a snapshot from that morning.

• CVE Program metrics: published records by quarter, reserved IDs, and the numbering-authority versus last-resort split. The 2026 column there runs through the third quarter.
• Vulnerability trends, overflo.ws: publication-date counts, severity, and CISA KEV additions. Page built 15 November 2026, 10:35 GMT.
• The Register, 13 November 2026: VulnCheck's 100,222 count, the exploitation-timing figures, the Copeland honeypot note, and the curl reporting change.
• Google Threat Intelligence Group, 30 September 2026: disclosure pace, exploitation, the AI-discovered risk mix, and CVEs in the AI stack. Their window ends 31 August 2026.
• Justin Middler, 23 October 2026: weekly volume, and the count of CVEs that say they were found with AI. Data through 18 October 2026.
• CISA BOD 26-04, 10 June 2026, and Cybersecurity Dive on the remediation timelines.
• CISA Known Exploited Vulnerabilities catalogue.