One count puts the number of CVEs published in 2026 above 100,000, with more than six weeks of the year still to go. The pressure falls hardest on the people who receive vulnerability reports, and UK organisations running disclosure programmes and bug bounties should plan for that now.
What happened
On Friday 13 November 2026 the vulnerability intelligence firm VulnCheck said the number of Common Vulnerabilities and Exposures (CVE) identifiers published this year had passed 100,000. Josh Bressers, who leads coordinated disclosure there, told The Register that the count stood at 100,222 at around 16:00 UTC. That is more than double the total for the whole of 2025.
These figures come from one company’s count, reported in one interview, and they should be read that way. WindowsForum noted that an NVD-based dashboard showed a figure a few hundred lower on the same day. Trackers draw on different feeds, so the direction matters more than the exact figure. Earlier forecasts, including the one from the incident response body FIRST, put the expected figure for 2026 nearer 60,000.
Bressers was blunt about the cause. He said AI-assisted vulnerability hunting accounts for most of the growth. He described the large CVE Numbering Authorities (CNAs), the organisations allowed to issue CVE IDs, including VulnCheck itself, Microsoft, Oracle and GitHub, as overwhelmed by the volume. Microsoft alone added 1,094 CVEs on November’s Patch Tuesday, after 1,474 in October.
The detail
Three points matter for anyone running a disclosure process.
First, the exploited share has barely moved. According to VulnCheck, about 1.4 per cent of this year’s CVEs (1,363) are in its own Known Exploited Vulnerabilities catalogue. That catalogue is broader than CISA’s KEV list. A steady percentage of a figure that has doubled still means roughly twice as many exploited bugs to deal with.
Second, attackers are moving faster. VulnCheck says the median gap between a CVE going public and its exploitation shrank from 120 days last year to 80 across January to June, and Bressers said it has narrowed again since. He pointed to 14 root-level flaws VulnCheck disclosed on the same Friday in Copeland refrigeration controllers. He said honeypot hits began within minutes, and two of the flaws are already being exploited. CrowdStrike separately reported that 88 per cent of the exploitation it saw in the first half of the year, where public proof-of-concept code was involved, came within 48 hours of that code appearing.
Third, the number may overstate how many new bugs were actually found. WindowsForum’s analysis cites supply-chain firm Safeguard, which found 373 CVEs issued at least three months after the matching advisory, most of them by VulnCheck. Some of this year’s growth is paperwork catching up with bugs that were already fixed. AI may well be the main driver, but the case rests largely on self-attribution and timing.
The strain on open source is not new to readers here. We covered curl’s move to handle low and medium severity reports in public on GitHub from 26 October, after it had already closed its bug bounty, and VulnCheck’s audit of Anthropic’s Glasswing findings earlier this week. Bressers offered his own summary: “We have a data problem now.”
Why it matters for UK organisations
Most UK coverage of CVE volume is about patching. The less discussed problem is at the front of the pipeline, where a report first arrives. Government departments, NHS bodies, universities and many private firms now run a vulnerability disclosure policy, via a platform, a security.txt file or an inbox. NCSC and wider government guidance encourage this, and the Cyber Security and Resilience Bill is expected to increase scrutiny of how regulated suppliers manage their exposure.
Those programmes were sized for human-paced research. When the same AI tooling that is pushing the global count past 100,000 is aimed at a UK web estate, the effect is more submissions, more duplicates and more reports that look plausible but turn out not to be exploitable. A triage team of one or two people that once handled a manageable trickle can find itself with a backlog, and a backlog in a disclosure programme is a risk in itself. Genuine reports wait in the queue, researchers lose patience, and the gap between a private report and public disclosure gets narrower.
Bug bounties face a further problem. Paying per valid finding works when findings are scarce. If AI makes them cheap, budgets drain faster and disputes over duplicates and scope multiply.
Expert view
In my experience, most organisations measure their disclosure programme by whether reports come in. Very few measure whether they can process those reports. When we test a client’s VDP, the usual failure is not a missing policy. It is a policy that sends reports to an inbox nobody owns, with no service levels, no agreed severity model and no route to the engineers who can fix the problem.
The 100,000 figure should change that. Being swamped with reports is now a predictable risk to plan for. I would treat the intake process like any other production service: define capacity, set response targets you can actually meet, and decide in advance what you will do when volume doubles. Bressers’ point about prioritising by real-world exposure rather than raw severity applies to incoming reports just as much as to patch queues. A medium-rated flaw on an internet-facing login page matters more than a critical one in a library you do not ship.
I would not take any single count as gospel either. These figures come from one vendor that is also a large CNA. Benchmark against your own data, not a headline.
What to do now
- Check that your VDP actually works. Confirm a named owner, a monitored channel, a current security.txt and published response times. Send a test report end to end.
- Plan for at least double the volume. Agree how you will handle a surge, whether through extra staff, platform-managed triage or a temporary pause on low-severity categories, before you need it.
- Triage by exposure, not score alone. Rank incoming reports and outgoing fixes by internet exposure, evidence of exploitation and how easily the attack could be automated, with CVSS used to break ties. This supports the Cyber Essentials security update management control.
- Revisit bounty economics. Review scope, duplicate rules and reward tables so that a flood of AI-generated low-quality reports cannot drain the budget. Require reproducible proof of impact.
- Shorten your patch windows for exposed assets. If exploitation now starts within hours of publication, the Cyber Essentials 14-day limit for high and critical fixes is a ceiling, not a target.
- Track your open source dependencies. Upstream maintainers are under strain. Know which projects you depend on and how they handle disclosure.
Bottom line
Passing 100,000 CVEs is a milestone in volume. It does not mean the risk to each organisation has doubled, but it is a clear warning about capacity. The exploited share is holding at around 1.4 per cent, yet that is now a much bigger number of bugs, and they are being exploited sooner. UK organisations that treat disclosure intake and bounty triage as something to engineer properly, rather than a mailbox, will cope with the surge better.
