The CVE flood of 2026: is AI finding the bugs, and who has to fix them?

The vulnerability count that software teams live by has broken its own scale. In 2025 the CVE Program published about 4,000 vulnerability records a month. In September 2026 it published 14,940 [REFRESH]. Between January and mid-October 2026, 80,793 CVE records were published, more than in the whole of 2025 (48,152), and the year is on course to pass 100,000 [1]. The question this review asks is simple: is artificial intelligence (AI) doing this? The honest answer from the public record is: partly, visibly, and not yet provably for most of the increase.

At a glance

• Monthly CVE publications rose 3.5-fold in nine months, from 4,302 in January 2026 to 14,940 in September [1] [REFRESH].
• Six issuers account for four-fifths of the increase. GitHub, VulnCheck, Microsoft, Google Chrome, Oracle and the Linux kernel team together added 26,300 more records than in 2025; the other 385 numbering authorities added 6,300 [1].
• The mix is getting more serious, not less. Critical and high-severity records are 52% of 2026's scored CVEs, against 41% in 2025; the count of critical records (9,141) is already more than double 2025's [1].
• AI is now named on the credit line of about one CVE in a hundred. 566 records published in 2026 credit an AI system or an AI discovery programme, up from 33 in 2025, and the monthly count went from 18 in January to 152 in September [1].
• The AI software stack is itself a vulnerability source: 2,137 records in 2026 for AI frameworks, model servers, agents and chat front ends, nine times 2025's count [1].
• Exploitation is growing far more slowly than disclosure. CISA's Known Exploited Vulnerabilities (KEV) catalogue added 261 entries in 2026 to mid-October, against 245 in all of 2025, but the gap between a CVE's publication and its KEV listing has halved, to a median of 12 days [2].

The numbers

The CVE Program (run by MITRE for the US Cybersecurity and Infrastructure Security Agency, CISA) publishes one record per vulnerability. It is the register that scanners, patch tools and compliance checklists are built on. We counted every record in the Program's own list by its publication date, not by the date the US National Vulnerability Database (NVD) got round to analysing it, and excluded rejected records [1].

The curve is not a spike. Every month from February to September 2026 was higher than the one before, bar a dip in April. Growth of 20% to 40% a year had been normal since 2017; 2024 was up 38% on 2023, 2025 up 21% on 2024. The first nine and a half months of 2026 are up 68% on the whole of 2025 [1].

Google's Threat Intelligence Group (GTIG), whose September 2026 analysis prompted this review, reports a doubling from 5,045 disclosures in January 2026 to 10,740 in August [3]. Its figures come from Google's own tracking rather than CVE publication dates, so they differ from ours, but the direction and the scale are the same.

Who is issuing them

A CVE is assigned by a CVE Numbering Authority (CNA): a vendor, an open-source project, a bug-bounty platform, a security company or a national agency. There were 391 active CNAs in 2026, only 26 more than in 2025 [1]. The increase did not come from more issuers. It came from a few existing issuers publishing far more.

Three of those stories are about open-source software. GitHub, which assigns CVEs for advisories on open-source repositories, went from 2,866 records in 2025 to 11,606. VulnCheck, a security company that assigns CVEs for projects that have no CNA of their own, went from 1,073 to 7,976, including more than 600 for one AI agent project, OpenClaw [1]. The Linux kernel team added 1,750 more than in 2025 but, at 9% of all 2026 records, it is a smaller share of the total than it was.

Three are about large vendors. Microsoft published 1,244 records in 2025 and 4,378 in 2026 to mid-October; its monthly count went from 125 in January to 1,000 in September, and 1,416 in the first two weeks of October [1] [CHECK: Microsoft's own explanation; it has said nothing public that we have found]. Google Chrome went from 195 to 3,230. Oracle's quarterly patch bundles went from 314 to 3,076. None of these records says how the bugs were found.

Is it AI? Three tests

The CVE record has no field for "found by AI". GTIG makes the same point and warns that public data "significantly undercount" AI-found bugs, partly because cloud providers fix what their agents find without ever requesting a CVE [3]. So we looked for AI in the three places it can be seen.

Test 1: the credit line. Most CNAs name who reported a bug. We searched every 2026 credit line for the name of an AI system or an AI-discovery programme: Claude or Anthropic Research, Aisle, Google Big Sleep, XBOW, Hacktron, OpenAI's Aardvark, ZeroPath, or wording such as "AI-assisted" or "discovered by an LLM". A researcher who merely works at an AI company does not count.

The answer is 566 records in 2026 to mid-October, about 0.7% of the year's total and 1.0% of September's. That is a floor, not a count: the credit line is optional, many CNAs leave it blank, and a bug found with AI help by a human researcher is usually credited to the human. But it is already a different kind of entry in the register. The Apache Software Foundation credits "The ASF using Claude Agents" for a critical flaw in Apache Storm. Mozilla's February 2026 Firefox release credited a team of Anthropic researchers "using Claude" for nine critical memory-safety bugs. The curl project credits Aisle Research for a critical flaw. In each case a maintainer, not a stranger, chose to run an AI over its own code and publish what it found [1].

The pattern matches GTIG's finding from its own data: AI-found bugs skew towards memory corruption in C and C++ code, the class of flaw that attackers most want and that static analysers have missed for decades [3]. On the CVE record's own severity scale they are not, on average, more severe than the rest of 2026's crop. That matters for the people who have to patch them: these are real, exploitable classes of bug, landing in the libraries (OpenSSL, curl, FFmpeg, Wireshark, Firefox) that everything else is built on.

Test 2: the AI software stack. The second place AI shows up is as the thing being broken. We counted records whose affected product is an AI framework, model server, agent, chat front end or vector database (vLLM, Ollama, Langflow, Flowise, Open WebUI, LiteLLM, OpenClaw and about sixty others).

GTIG counts 2,076 AI-stack CVEs over January 2025 to August 2026 by its own taxonomy and finds half of them in agent-orchestration frameworks, where a prompt or a crafted workflow file can become remote code execution [3]. Our count is of the same order. Whoever is finding them, the attack surface being catalogued is new, and much of it is a year or two old.

Test 3: the vendor floods. The largest single contributors to the 2026 increase, GitHub-issued open-source advisories, Microsoft, Chrome and Oracle, are also where the record is silent. Microsoft's eightfold monthly rise and Chrome's sixteenfold yearly rise are consistent with vendors running AI-assisted code review at scale and publishing what it finds, which is exactly what GTIG recommends software producers do [3]. They are also consistent with policy changes about what gets a CVE at all. We cannot tell from the data, and neither company has said [CHECK: ask Microsoft MSRC and Google for comment before publication; check MSRC blog for any 2026 policy post].

So: AI is measurably in the register, at about one record in a hundred and rising fast; AI software is a growing target; and the biggest unexplained growth sits with a handful of large issuers who may or may not be using AI to find what they publish. "AI caused the CVE flood" is a plausible hypothesis. The public record does not yet prove it.

More of them, and more serious

Whatever is finding the bugs, they are not trivia. The share of scored records rated critical or high has risen every year since 2023.

In 2026 to mid-October, 9,141 records were rated critical and 32,778 high, together 52% of scored records. In 2025 the figures were 4,111 and 15,764, 41% [1]. Monthly critical records went from 428 in January 2026 to 1,815 in August. GTIG, using its own risk ratings rather than CVSS, saw high-risk disclosures rise 167% between January and August and traced the peaks to Oracle's patch bundles, Linux kernel driver advisories and a batch of consumer-router flaws [3].

Exploitation: growing, but slower than disclosure

The register measures what is found and published. CISA's KEV catalogue measures what attackers actually use. It is the only public, government-maintained list of vulnerabilities known to be exploited in the wild, and US federal agencies must patch what is on it by a deadline [2].

CISA added 261 vulnerabilities to the catalogue in 2026 to 14 October, already more than 2025's 245, with September 2026 (43) the busiest month since the catalogue's first year [2]. Against 80,000 published records that is one in 300. GTIG's own exploitation tracking tells the same story: 141 distinct exploited vulnerabilities in the first eight months of 2026 against 127 in all of 2025, with zero-day exploitation up only marginally and most growth in "n-days", bugs weaponised soon after public disclosure [3].

That last point is where the data turns practical. We matched each KEV entry to its CVE publication date.

Half of what gets exploited in 2026 is exploited within 12 days of its CVE appearing, down from 23 days in 2025. The share exploited as a zero-day is unchanged at about a fifth. That is consistent with GTIG's suggestion that attackers are using AI to turn patches and advisories into working exploits faster, rather than to find new zero-days [3]. It is also the number that should set a development team's patch window.

What it means for software teams

• Budget for triage, not for the count. At 15,000 records a month no team can read them all. The questions are which of them touch code you ship or run, and which are on the KEV list or have a public exploit. A software bill of materials (SBOM) and a feed that joins CVE, KEV and your dependency list is now the minimum.
• Twelve days is the new patch window for anything exposed. Half of exploited 2026 vulnerabilities were in use within 12 days of publication. Internet-facing systems, edge devices and anything on the KEV list need a path to patch inside that.
• Expect your own dependencies to be audited by AI, whether you asked or not. The maintainers of OpenSSL, curl, Firefox, Apache projects and the Linux kernel are already publishing what AI finds in their code. Those fixes arrive as ordinary upstream releases; the cost falls on whoever has to rebuild and redeploy.
• Run the same tools first. The organisations crediting AI on their CVEs chose to point it at their own code before someone else did. GTIG argues that if pre-release AI code review becomes standard, public disclosure growth could eventually slow [3].
• Treat the AI stack as production software. Agent frameworks, model servers and chat front ends generated more CVEs in 2026 than the whole of the previous five years of the same products. Patch them, put them behind authentication, and do not give an agent more reach than the task needs.
• Watch the numbering authorities, not just the numbers. If Microsoft, Google or GitHub change what they assign a CVE for, the global count moves without the world getting less safe. Ask what changed before reading a trend into it.

This is a summary of public data, not security or legal advice.

Method

All CVE figures are our own counts from the CVE Program's bulk CVE List V5 download (records in state PUBLISHED, by their datePublished field). The pipeline, classification rules and a summary file are in the Cyber Risk Barometer repository (scripts/cve-parse.py, scripts/cve-stats.py, data/cve/summary.json) and will be re-run in the week before publication so the article covers January to November 2026 [REFRESH]. Severity uses the CVSS base severity recorded by the CNA, or failing that by CISA's enrichment programme; about 6% of 2026 records have no score and are left out of severity shares. "AI-credited" means the CNA's credit text names an AI system or an AI vulnerability-discovery programme (Claude or Anthropic Research, Aisle, Google Big Sleep, XBOW, Hacktron, OpenAI Aardvark, ZeroPath, or explicit "AI-assisted", "AI agent" or "LLM" wording). It is a floor. "AI stack" means the first affected product name matches our list of about sixty AI frameworks, servers, agents, front ends and vector databases; it also under-counts. KEV lag is the difference between a vulnerability's dateAdded in the KEV catalogue and its CVE publication date, for entries whose CVE could be matched. GTIG's figures are quoted from its 30 September 2026 post and are not directly comparable: it uses its own data, its own risk ratings and its own definition of AI-discovered.

Sources

1. CVE Program, CVE List V5 bulk download (release of 15 October 2026): https://github.com/CVEProject/cvelistV5/releases. Record format: https://cveproject.github.io/cve-schema/schema/docs/. Linux kernel CNA policy: https://docs.kernel.org/process/cve.html
2. CISA, Known Exploited Vulnerabilities catalogue (JSON feed, version 2026.10.14): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
3. Google Threat Intelligence Group, "Vulnerability Discovery and Exploitation Trends in the AI Era", 30 September 2026: https://cloud.google.com/blog/topics/threat-intelligence/vulnerability-discovery-and-exploitation-trends-in-the-ai-era
4. CVE Program, list of CVE Numbering Authorities: https://www.cve.org/PartnerInformation/ListofPartners