The CVE Flood: Why 2026 Broke the Vulnerability Count

analyst@unixshadow: ~/cve-count/2026.log
analyst@unixshadow:~# curl -s “https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2026-10-01T00:00:00.000Z&pubEndDate=2026-10-26T00:00:00.000Z&resultsPerPage=1” # totalResults: 13934

The CVE Flood: Why 2026 Broke
the Vulnerability Count

October 2026 published more than three times as many vulnerability records in 25 days as all of October 2025 — and the year is already past 88,000. The count is real. What it means is not what the headlines say.

# the number — what the count actually says
october: 13,934 CVE records published Oct 1–25, 2026 (NVD, by publication date, checked Oct 26). All of October 2025 published 4,389. October 2026 is running 3.2 times last October’s total — about 557 records a day.
the year: 88,017 records published Jan 1–Oct 26, 2026 (NVD publication-date counts, same check). That is nearly double 2025’s full-year total of about 48,000 — with two months still to run.
the denominator: CISA added 272 vulnerabilities to its Known Exploited Vulnerabilities catalog in 2026 (26 in October, same CISA feed check). That is about 3 exploited flaws for every 1,000 CVE records. A CVE is a disclosure record, not evidence of exploitation.
the fine print: headline October counts include records later rejected — one analysis of the same NVD data counts 202 of the 13,934 in that bucket. Counting bases differ between trackers, which is why year-to-date totals disagree by a few thousand depending on who counts.
Counting CVEs to measure risk is like counting raindrops to measure a flood: technically related, useless for deciding what to sandbag.
# what is driving it — three drivers, one caveat
AI-assisted hunting, at scale: Microsoft began hunting with AI systematically across its codebase in 2026. Its Patch Tuesday totals tell the story: 206 CVEs in June, 569 in July, about 973 in September, 1,413 in October — a record, including one already under attack. Microsoft’s VP of Engineering, Tom Gallagher, said in June that AI-assisted discovery was enabling bug hunting “at a speed and scale previously unseen.”
the flagship example: PHP2Shell (CVE-2026-109618 and CVE-2026-109619), the October critical pair in the PHP interpreter, was found with AI assistance — Calif and Wiz researchers working with frontier models, under OpenAI’s Patch the Planet program and independently. Flaws that sat unexploited for years became mass-scanning targets within hours of disclosure. (Our full breakdown: PHP2Shell: Two Bugs That Turned Requests Into Shells.)
more disclosure, not just more bugs: the October increase is concentrated among a few large vendors — one analysis counts Microsoft at 1,455 October records against 180 in October 2025, and Oracle up from 78 to 1,078. There are now close to 500 CVE Numbering Authorities. When one big vendor changes how it discloses, the global total moves.
the caveat: only about 1.4% of October records — around 200 — explicitly credit an AI lab, model, or AI security firm, and 54% name no finder at all. The records cannot prove AI’s share of the flood. As the Zero Day Initiative’s Dustin Childs put it, AI is not creating these bugs out of thin air; it is shortening the time between a vulnerability existing and someone noticing it.
So the flood is not proof software got worse. It is proof discovery got faster and disclosure got wider — and those are different problems with different fixes.
# why patches lag — the gap that matters
discovery → fix → deploy is a pipeline, and every stage queues: Anthropic’s disclosure dashboard, as of Oct 2, listed 6,157 vulnerabilities reported to maintainers, with 516 patched to the company’s knowledge. That is one program’s snapshot, not an industry rate — status data is incomplete and changes — but it shows the shape of the gap: finding is now the fast part.
exploitation is faster than patching: CrowdStrike observed that in the first half of 2026, 88% of exploitation of vulnerabilities with a public proof of concept happened within 48 hours of that proof of concept’s release. PHP2Shell drew exploitation attempts before the fix was even public. The grace period between disclosure and weaponization is gone.
the database itself stopped keeping up: since April, NIST no longer adds its own analysis to every CVE — it prioritizes KEV entries, software used by the US federal government, and critical software. Everything else is marked “Lowest Priority — not scheduled for immediate enrichment.” A process that waits for an NVD score before patching is waiting for a train that is not coming.
This is the part that changed. The count is the headline; the shrinking window between disclosure and exploitation is the story.
# the triage rule — what to patch first
1. KEV + you run it → now. The exploited set is tiny — 272 additions this year — and it is the only list that means “attackers are using this.” If it is on KEV and in your stack, nothing else outranks it.
2. internet-facing + public proof of concept + critical → hours. Not the monthly cycle. The 48-hour exploitation window does not care about your patch window.
3. everything else → the scheduled cycle. A CVE count is not a priority list. Patching by volume is triage by the one thing the flood guarantees.
0. know what you run. You cannot triage what you have not inventoried. The teams coping with the flood are the ones that already know their stack — versions, exposure, and which systems face the internet.
Or, as Childs put it: patch what is proven, prioritised, and public — and treat everything else as this month’s new normal.
# quick reference — the whole post in three lines
The numbers: 13,934 records Oct 1–25 (3.2× October 2025); 88,017 this year; 272 KEV additions.
The drivers: AI-assisted hunting + wider disclosure + faster weaponization. AI’s exact share is unproven — 1.4% of records credit it explicitly.
The rule: KEV first, internet-facing with a PoC second, everything else on cycle. Never by count.
Sources: NVD API publication-date counts and the CISA KEV feed, checked Oct 26, 2026; Microsoft October Patch Tuesday reporting; Anthropic’s disclosure dashboard (Oct 2 snapshot); CrowdStrike H1 2026 observations; ZDI comment to Computer Weekly.
# glossary — the alphabet soup, decoded
CISA
Cybersecurity and Infrastructure Security Agency (US). Runs the KEV catalog; US federal civilian agencies must patch KEV entries by its due dates.
CNA
CVE Numbering Authority: an organization authorized to assign CVE IDs within its own scope — vendors, open-source projects, national CERTs. Close to 500 exist.
CVE
Common Vulnerabilities and Exposures: a unique ID and public record for one specific vulnerability. A record, not a verdict — it says nothing by itself about exploitation.
CVSS
Common Vulnerability Scoring System: the 0–10 severity score attached to many CVEs. 9.0 and up is “critical” — but a high score without exploitation evidence is still not a patch-first signal on its own.
CWE
Common Weakness Enumeration: the taxonomy of bug types (buffer overflow, SQL injection) that a CVE instance belongs to.
KEV
Known Exploited Vulnerabilities: CISA’s catalog of flaws with confirmed real-world exploitation. The smallest, most urgent list in this post.
NIST
National Institute of Standards and Technology (US). Runs the NVD.
NVD
National Vulnerability Database: NIST’s database of CVE records, enriched with scores and analysis — except since April 2026 it no longer enriches every record.
PoC
Proof of Concept: public exploit code, or a demonstration that a flaw is exploitable. A published PoC is what starts the 48-hour clock.

Series: AIStatus: Published 26 Oct 2026

Scroll to Top