The cost of finding vulnerabilities has collapsed while the cost of proving, approving, and deploying a patch remains fixed. Project Glasswing’s analysis makes the point directly: the bottleneck has moved from discovery to remediation, as automated tools operate at machine speed while engineering teams operate at human capacity. Google Threat Intelligence Group counts monthly disclosures rising from 5,045 in January 2026 to 10,740 in August, doubling in eight months. Remediation throughput still scales with team size, code review capacity, and scheduled release windows.
A rising count reflects more automated observation. The exploited minority behind it is small and roughly stable. That is a fixed cost per record. You can explain this gap in a budget conversation once you understand where the identifier comes from and the discovery-to-remediation asymmetry.
Why is vulnerability disclosure volume growing faster than anyone’s ability to patch?
The imbalance begins with how flaws are surfaced. Automated tools scan repositories continuously, while patch verification, testing, and deployment remain bound to human schedules. Records arrive in a stream your team did not ask for. A CVE record dates an observation. It carries no measurement of exploitability.
Vendor output illustrates this scale. Tenable reported that Microsoft published 1,407 CVEs in its October 2026 Patch Tuesday update, with Tenable counting 69 in its highest severity tier.
The volume increase is broad. VulnCheck tracked published CVE growth through 2026, finding Chrome disclosures up roughly 563 percent year to date and VMware up 181 percent. FIRST noted that GitHub Security Advisory volume rose 449 percent year over year, with total disclosures tracking towards 66,000 for 2026 against 48,185 in 2025 and roughly 40,000 in 2024. The share of highest-severity flaws fell from roughly 13 percent to 7 percent.
The timing and breadth align with AI-assisted vulnerability discovery tools. Attribution remains inferential because no public registry carries an AI-attribution field, so the correlation is strong and the causal share is not public. This influx has strained the enrichment pipeline. The National Vulnerability Database (NVD) converts raw identifiers into structured records, but NIST adjusted its enrichment scope after annual submissions rose 263 percent between 2020 and 2025, leaving tens of thousands of records awaiting analysis. Every unenriched record still lands in your queue as a ticket, which leaves the question the volume data cannot answer: how many of those records describe something anyone is exploiting?
How many disclosed vulnerabilities are actually exploited in the wild?
A higher volume of records has not produced an equivalent rise in active attacks. During the same January to August 2026 window where disclosures doubled, Google Threat Intelligence Group tracked 141 newly disclosed flaws exploited in the wild. That is 141 records out of roughly 61,000 disclosures: about one in 431.
When your team triages by volume, you spend most of your week on records nobody has been observed exploiting. Qualys TRU finds that the fraction of disclosed vulnerabilities weaponised in real-world scenarios stayed below one percent in 2025 even as volume nearly doubled. Google Threat Intelligence Group found that edge devices, network gateways, and identity systems accounted for a concentrated share of those active flaws. Furthermore, Armorcode’s analysis notes that CISA’s Known Exploited Vulnerabilities Catalog (KEV) contains fewer than 1,700 items out of more than 300,000 published CVE records.
A ratio of one in 431 is an observed baseline across telemetry, not a guarantee of safety for unmonitored systems. Actively exploited flaws stay roughly stable while disclosures surge. The workload therefore comes from triage, verification, and change management.
Why is the Linux kernel producing close to 2,000 CVEs per release instead of 500?
The kernel now produces close to 2,000 CVEs per release, against roughly 500 through much of the 6.x series, because more of it is being examined. As Tom’s Hardware reported, automated tools began scanning more than 40 million lines of source code, flagging minor edge cases in legacy drivers and obscure hardware modules. The kernel code did not degrade.
This automated volume adds administrative work for maintainers. Help Net Security quoted Linus Torvalds explaining that the security mailing list had become “almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools.” Torvalds was describing a triage problem.
Trend Micro calculated that across more than 5,800 kernel CVEs, real-world exploitation sits on the order of 0.02 percent. The Linux kernel stands as both the largest source of published identifiers and one of the least exploited components in production. A rising kernel line on your dashboard registers review activity: the number measures how much scrutiny the code received.
What is a CNA, and why can one project’s naming policy inflate the count without adding risk?
Why some projects generate more records from the same scrutiny comes down to who is allowed to assign the number. A CVE Numbering Authority (CNA) is an organisation authorised to issue CVE identifiers within a specific scope. As Epoch AI outlines, the CNA framework decentralises assignment, allowing project teams and vendors to issue identifiers directly rather than waiting for a central registry.
Decentralised naming means assignment thresholds depend on local project policy. When an organisation becomes a CNA, its vulnerability volume reflects internal tagging rules. A CNA covering a content management plugin ecosystem might issue a record for every minor input flaw, while a software vendor might batch updates together. The kernel is also the clearest case of this labelling policy. As The Register reported, the Linux kernel team adopted a policy of assigning a CVE to nearly every bugfix committed to stable branches. This provides commit-level traceability, but produces an influx of identifiers for defects that carry no practical exploit path. Analysis by security researcher Jerry Gamblin showed that 97.5 percent of kernel CNA records never state a security impact.
Each entry then passes through two more hands. A CNA assigns the identifier, NIST attempts to enrich the record, and scanners ingest the result. Because severity scores are the slowest part of the pipeline, raw counts can reach engineering backlogs long before anyone verifies their severity. This is the mechanism behind the count you were asked about. You should never compare CVE counts across projects, vendors, or years without first asking who assigns the identifiers and under what rule.
The count grew while the exploited minority stayed small, yet your team spends the same hours validating every incoming ticket. The strain shows up in review backlogs and change approval meetings. A count that measures scrutiny is a workload signal, which matters because the exploitation window collapsed while the count grew.
Frequently Asked Questions
Does a rising CVE count mean my organisation is more exposed?
No. It means more of your code and your suppliers’ code has been examined and labelled. The count tracks scrutiny and labelling policy, not the number of ways an attacker can reach you. Exposure depends on what you run, how it is configured and whether anyone is exploiting it, so a doubled record count can sit alongside a flat exploited minority. Treat the number as a workload meter first.
What is the difference between a CVE and an actual vulnerability?
A CVE is an identifier, not a bug. It is a public record stating that a specific issue exists in a specific product, issued so defenders can discuss the same thing. Some records describe flaws with no demonstrated security impact, others real exploitable weaknesses. The identifier confirms someone assigned a number, nothing more, so treat it as a pointer to read rather than a verdict.
What does “exploited in the wild” actually mean?
It means someone has been observed using the flaw against a real target, outside a lab or a proof of concept. Telemetry from sensors, incident response and honeypots feeds that judgement, which is why the figure is a floor rather than a ceiling. A flaw can be exploited without anyone noticing, so absence from the exploited list is not evidence of safety.
Should we prioritise patching by CISA KEV instead of CVE counts?
Yes, KEV is a better starting point than a raw count, provided you do not stop there. The list holds flaws with confirmed exploitation, the signal that actually correlates with harm. It is deliberately conservative and lags discovery, so pair it with your own exposure data: internet-facing, privileged, or reachable from an untrusted network. Then work down by consequence, not volume.
Does the flood mean there are more zero-days than before?
Not necessarily. A zero-day is a flaw exploited before a fix exists. The disclosure surge is mostly flaws found and labelled, often long after the code shipped, rather than new attacks in progress. Nothing in the volume data shows attackers holding a larger stock of unknown bugs. It shows researchers, and their models, looking harder at code that was always there.
Can we just stop triaging every CVE?
You can stop triaging every record by hand, but not by ignoring them. The workable version is a filter: suppress records for software you do not run, group records that share a root cause and one fix, and route what remains by reachability and privilege. Otherwise most of your capacity goes to records nobody has been observed exploiting.
How do we tell an AI-found bug from a low-quality report?
Read the report, not the label. A credible finding names the exact function and version, includes a reproduction or a crash trace, and explains the path from attacker input to impact. Volume-driven noise tends to be vague on preconditions and heavy on severity language. Where a submission arrives with an identifier attached, check who assigned it and under what rule.
What happens if we cannot patch everything before the next disclosure wave?
Accept the queue and make the residual risk explicit. Fix what is reachable and exploited, document the compensating controls for what you defer, and record the decision with an owner and a review date. That converts an unbounded backlog into a bounded set of accepted risks. An unwritten deferral is the only version of this that is genuinely unmanaged.
If I find a vulnerability in open source code, should I report it?
Yes, but report it to the maintainer or the project’s security contact first and give them time to ship a fix. Coordinated disclosure is what keeps the identifier useful. Where the project is a CNA, it can assign the CVE itself. Where it is not, the request goes through MITRE or the relevant root. Publishing first mostly adds noise to a strained queue.
How much of the pressure is triage rather than patching?
More than most teams admit. Patching a known flaw is bounded work: a change, a test, a change window. The surrounding steps repeat for every identifier regardless of severity, covering record reading, applicability checks, scoring, documentation and approval. That fixed cost per record is why a doubled count feels like a doubled workload even when the genuine exposure has not moved.
