More CVEs in Q3 2026 than in any full year before 2024

Between July and September 2026, 36,953 CVEs were published.

That is more than any full year in the history of the CVE programme before 2024. In one quarter.

I have had a hunch for a while that AI was about to blow up vulnerability numbers. So I downloaded the entire CVE List, all 413,801 records, and ran the numbers. The hunch was wrong in one way. It isn’t about to happen. It already has.

The short version

CVE volume has more than doubled in 2026. 86,292 CVEs were published between 1 January and 23 October, against 38,569 in the same window of 2025. That is already 79% more than the whole of 2025.

The growth is not a counting trick. It isn’t old bugs being published late, and it isn’t new organisations joining the programme. The same issuers are simply publishing far more, and the curve is still bending upwards.

AI is the most likely driver. CVEs that credit an AI system as the finder went up 22x. But the more interesting story is what didn’t go up.

How big is the jump?

Here’s every like-for-like comparison, using the same dates in each year (1 January to 23 October unless stated).

	2025	2026	Change
All CVEs	38,569	86,292	2.2x
September	4,319	14,934	3.5x
Q3 (Jul to Sep)	11,722	36,953	3.2x
Critical severity	3,348	9,599	2.9x

September’s pace works out at one new CVE every 2.9 minutes. Around the clock. Weekends included.

And it is accelerating. January 2026 had 4,302 CVEs, which was normal by 2025 standards. Every month since has been bigger than the last, give or take.

Is it just a counting change?

That was my first question. CVE numbers have jumped before for boring reasons. In 2024 the Linux kernel started issuing its own CVEs and added thousands a year almost overnight. WordPress plugin security firms do the same.

So I tested the obvious explanations one by one.

Old bugs published late? No. Only 2.7% of CVEs published in 2026 carry an ID from before 2025. That is the lowest share of any recent year. The median gap between reserving a CVE and publishing it is 13 days, also the fastest on record.

New organisations joining? No. Organisations that published nothing in 2025 account for 1,662 of the 86,292. The organisations that were already publishing went up 2.2x between them. And 72% of established issuers grew.

Linux and WordPress? No. Strip out the Linux kernel, the three big WordPress issuers and VulDB, and everything else still went from 20,242 to 61,970. Three times bigger.

This is broad. It is everywhere at once.

The vendors’ own numbers

The biggest surprise for me was the major vendors. These are mature security programmes that have issued CVEs for their own products for years. Their numbers did not drift up. They jumped.

Vendor (1 Jan to 23 Oct)	2025	2026	Change
Google Chrome	110	3,593	33x
Oracle	314	4,153	13x
Apache	172	1,218	7x
Red Hat	250	1,236	5x
Microsoft	1,106	4,417	4x

Chrome is the one that stands out. It rated 4 of its CVEs critical in the whole of 2025. So far in 2026 it has rated 210 critical.

Here’s the thing though. None of these five vendors says in its CVE records who found the bugs. So the data shows that something changed. It can’t show you what.

Where AI shows up in the data

Some organisations do say who found their bugs. And that is where AI turns up, by name.

I counted every CVE whose finder credit names an AI system or an AI lab’s security research effort. Think “Discovered by Claude”, “Found by AISLE” and “Trail of Bits in collaboration with OpenAI”. Credits for AI that helped fix a bug don’t count.

	2025	2026
AI-credited CVEs, 1 Jan to 23 Oct	34	769

That’s 22x. And the monthly numbers are still climbing: 18 in January, 150 in August, and 199 in October with a week of the month still to go.

A few things jump out:

• Who: Anthropic and Claude are named in 335 of them, AISLE in 296 and OpenAI in 112.
• Where: Red Hat, Apache, Mozilla, curl, OpenSSL, wolfSSL, FreeBSD, PostgreSQL and GitLab. These are some of the most heavily reviewed codebases on the planet.
• How serious: 376 of the 769 are rated high or critical. These aren’t typos in a readme.

Now, 769 is under 1% of 2026’s total. But treat it as a floor, not an estimate. It only counts the organisations that publish credits, and the ones that write the AI tool into them. The vendors with the biggest jumps aren’t in that group.

So does the data prove AI is behind the surge? No. Does everything in it point the same way? Yes. The timing lines up, the growth is everywhere at once, and AI keeps finding real bugs in the hardest code there is.

AI is the target too

There’s a second AI story in the data, and it’s growing just as fast.

CVEs in AI software itself went from 505 to 3,191 over the same dates. That is 3.7% of every CVE published this year.

The single biggest source is OpenClaw, the open-source AI agent, with more than 600 CVEs of its own. Behind it come chat front ends like Open WebUI, agent builders like Flowise, model servers like vLLM, and a long tail of MCP servers that connect AI agents to everything else.

Every company that wired an AI agent into its systems this year has picked up a new place to look for vulnerabilities.

The number that didn’t double

This is the bit nobody seems to be talking about.

CISA assesses CVEs for active exploitation. Of the ones it has assessed this year, 195 were being actively exploited. Last year it was 163.

So volume went up 2.2x. Actively exploited CVEs went up about 20%. The share of CVEs being exploited roughly halved, from 0.45% to 0.25%.

That isn’t good news. It means the haystack doubled and the needles didn’t. Every security team now has to dig through twice as many vulnerabilities to find the same handful that actually matter.

Patching everything was never realistic. Now it isn’t even close. The skill that matters is triage. Reading a CVE, judging whether it touches your environment, working out whether it’s reachable, and deciding what waits.

What the data can’t tell you

To be straight about the limits:

• It can’t prove cause. Most big vendors don’t publish who found their bugs, so AI’s share of the surge can’t be measured directly.
• Process changes are possible. Part of a jump can come from a vendor changing how it assigns CVEs, such as one CVE per bug instead of one per patch. The vendor spikes landed in their regular patch releases, which fits either story.
• 2026 isn’t over. Every comparison here uses 1 January to 23 October in both years, so nothing is flattered by a partial year.

Quick answers

How many CVEs were published in 2026?

86,292 CVEs were published between 1 January and 23 October 2026, according to the CVE List. That is 2.2 times the same period of 2025, and 79% more than the whole of 2025 (48,151).

Why has the number of CVEs increased so much?

It isn’t late publication or new issuers joining. The same organisations are publishing far more, across nearly every vendor. AI-assisted vulnerability discovery is the most likely driver: CVEs crediting an AI finder rose 22x year on year. Vendors don’t disclose how their bugs were found, so its exact share can’t be measured.

Is AI finding more vulnerabilities?

Yes. CVE records crediting an AI system or an AI lab’s security research team as the finder rose from 34 to 769 over the same dates. They include high and critical bugs in curl, OpenSSL, PostgreSQL, Firefox and Apache projects.

Are more vulnerabilities being exploited?

Only slightly. CISA marked 195 of the 2026 CVEs it assessed as actively exploited, against 163 a year earlier. Volume more than doubled, so the exploited share roughly halved. The challenge for defenders is prioritisation, not volume alone.

Where CyberHire fits

A vulnerability count that doubles in a year changes what you need from the people you hire. Vulnerability management analysts, AppSec engineers and SOC analysts all spend more of their day deciding what doesn’t matter, so they can act on what does.

You can’t see that skill on a CV. You can see it in front of real code.

portal.cyber-hire.com/challenge/code Code review

That’s what our assessments do. Candidates review real code, work through real logs and make real triage calls, and every one is scored the same way. Send us the job spec and we build the assessment for you, ready to send to your applicants. See how it works for AppSec hiring.

Methodology

• Data: the full CVE List V5 bulk download from the CVE Program, taken on 23 October 2026. 413,801 records, of which 395,170 are published. Rejected records are excluded.
• Dates: each CVE is counted by its published date. Year-on-year comparisons use 1 January to 23 October in both years.
• AI as finder: a CVE counts when a finder or reporter credit names an AI system or an AI lab’s security research effort. Credits for remediation are excluded. Reference links are not used, because they often point to an AI vendor’s own advisories.
• AI as target: a CVE counts when the affected vendor or product is AI or LLM software, the description refers to LLMs, AI agents, MCP or prompt injection, or the weakness type is an AI-specific CWE.
• Severity: the newest CVSS version provided by the issuing organisation, otherwise CISA’s enrichment.
• Exploitation: CISA’s SSVC “active” exploitation flag, for the CVEs CISA has assessed.

The bottom line

The number of vulnerabilities more than doubled in a single year, AI’s fingerprints are all over it, and the people you hire now have to know which handful are worth their time.