With the explosion in the number of CVEs (Common Vulnerabilities and Exposures) being published, it begs the question as to whether the number of Known Exploited Vulnerabilities (KEV) is trending in the same direction. The natural assumption would be that there be some level of correlation. It took some exploring of data before we started to see any data trends that made sense, and threw up some interesting observations.

Before we look at what we might be able to infer from the data and the patterns we see, let’s start with the looking at the data we’ve sourced and plotted.

Data sources

• CVE Publications — CRACI / CVE Program: Monthly counts of published Common Vulnerabilities and Exposures (CVEs), categorized by CVSS severity: Critical, High, Medium, Low and Unknown. The data originates from the CVE Program’s official records and is presented as stacked areas to illustrate changes in vulnerability volumes and severity distribution over time. Sources: CRACI CVE Publication Trends | CVE Program GitHub.
• CISA Known Exploited Vulnerabilities (KEV): Monthly counts of vulnerabilities added to the US Cybersecurity and Infrastructure Security Agency’s catalogue of vulnerabilities confirmed to have been exploited in the wild. Counts are based on the date vulnerabilities entered the catalogue rather than when exploitation first occurred. Presented as the red line. Sources: CISA KEV Catalogue | CISA KEV GitHub.
• CIRCL Vulnerability-Lookup: Monthly deduplicated counts of vulnerabilities recorded across multiple exploitation intelligence catalogues, including CISA, Shadowserver, ENISA, Previdian and CIRCL. By aggregating these sources, it provides broader visibility of known exploitation than any individual catalogue, although counts reflect when vulnerabilities were listed rather than necessarily first exploited. Presented as the purple line. Sources: CIRCL Vulnerability-Lookup | GitHub Repository.
• VulnCheck KEV: Monthly counts of vulnerabilities identified as exploited in the wild through intelligence collected from security researchers, vendors, incident investigations and other publicly available evidence. VulnCheck provides an additional perspective beyond CISA, although its reporting volumes may be influenced by changes in intelligence coverage and retrospective discoveries. Presented as the thinner teal line, with the monthly figures currently treated as provisional pending independent validation. Sources: VulnCheck | Exploit Intelligence Documentation.

Understanding the data

Spikes in KEV data and varying sources

We have seen (and it is visible in our graph that the different sources of KEV data tend to show early spikes, typically triggered when the catalogue is being populated with retrospective data. We initially started looking at individual reporting sources such as VulnCheck thinking that they would give a true figure and the aggregated reporting data such as CIRCL would provide amplified patterns. The opposite appeared to be the case. We’ve kept the VulnCheck and CISA KEV reporting help illustrate this. Where Vulncheck’s spiking tend to be dramatic compared where CIRCL might show a small uptick, but then in the last quarter of 2025 we start to see opposing trends. It appears that CIRCL’s aggregation of sources has smoothed out the fluctuations. CISA’s KEV numbers in comparison a notably different in volume to VulnCheck. The CISA numbers generally follow the same pattern as CIRCL until 2026 – with the worst divergence 50 exploitations identified rather than the triple digit variance of VulnCheck.

Critical and High CVE fluctuations

If you look carefully and the CVE trends in the different categories, while there is clearly an acceleration in the last 12 months (which we could attribute to initiatives such as GlassWing) if you look carefully, you’ll notice that the growth in Severe and High scoring CVEs is growing faster. It is only two dates, but this table supports the observation:

Severity	September 2025	September 2026	Growth
Critical	295	1,555	+427%
High	1,275	6,160	+383%
Medium	2,331	5,285	+127%
Low	148	564	+281%
Unknown	263	1,366	+419%
Total	4,312	14,930	+246%

The telling difference is if you compare the total growth against the growth numbers and the individual severity growth numbers. The critical numbers have multiplied by nearly 1.75.

Exploits (KEV) appear to be tracking vulnerabilities (CVE)

Perhaps the most important, point in the data is that based on the aggregated CIRCL counts, exploits are following the upward trend with a bit of lag which fits what thought we’d see. Yes at this point we’re are mindful that this could be finding data that supports a hypothesis (particularly given other individual KEV numbers may not support the trend). But on balance I’m inclined to trust the CIRCL numbers because if other numbers are erratic we’d not see such a similar upward track.

How is patching performance responding?

Keeping up with patching is likely to prove challenging, the 2026 Edgescan report picks out a rather telling observation, which supports the problems of not keeping up:

The most striking insight is that vulnerabilities from 2025, 2023, and 2024 account for more than 50% of all occurrences, indicating that newly published or recently discovered issues are the primary drivers of risk this year.

The suggestion is that the really high profile vulnerabilities get addressed, but the progress to address those that don’t get the notoriety is weaker. The alternative possibility relates not on individual exposures but when failures grab the headlines that attention turns back to patching. Another indicator that patching can’t keep up is the Verizon 2026 DBIR reported 26% of CISA KEV vulnerabilities fully remediated in its analyzed population versus 38% in the prior report, with median full remediation time increasing from 32 to 43 days (assuming Verizon’s dataset is representative).

Conclusion

While this is not an exhaustive analysis, it would be fair to treat it as anecdotal evidence to indicate:

• CVE acceleration is being followed by KEV acceleration – possibly the most concerning.
• If historic data shows we can’t keep up with patching, then its only going to get worse – supporting the expectation of climbing KEVs.

We do therefore need to look to adopt differing strategies to protect ourselves, and new measurements to reflect whether the new approaches are paying dividends. So what can we do differently, and I’m not saying don’t patch, I’m saying if you have a finite patching capacity, use it wisely, and invest in actions that give you the best vulnerability reduction.

Steps

Patching is by its very nature after the horse has bolted, this is why we have zero day exploits. The bottom line is there will always be vulnerabilities, the question is who finds them first and how do we react. Perhaps an exceptional illustration is the Apollo 11 Guidance Computer 1201 and 1202 errors (more about this and other aspects of the Apollo program at Apollo 11 Journals, the BBC also have an excellent podcast – 13 Minutes to the Moon that broke this down). This essentially was a memory overload error (should sound familiar as it is an attack vector, only difference is the overload was innocent for Apollo 11). The lesson is, the ground crew had encountered various issues during training, so put operational processes in place to allow them to quickly determine cause and action. Just as with modern businesses, the lunar programme could not be stopped to create months to rework Apollo’s software to avoid the issue, so they ensured there are what we might call compensating controls – a manual ground crew process that could tell Armstrong and aldrin what to do.

Continuing compensating controls, is not to have reactions ready, but also preventing attacks from reaching vulnerabilities. For example Oracle’s WebLogic Server has some CVEs around its T3 protocol. If you’re not using this as a communication channel between severs you can switch it off in the configuration. Better still, put those servers within a subnet with network security rules that prevent T3 traffic from getting into the subnet. There are multiple CVEs for T3 – so rather than patching everyone one of them, you’ve prevented the exploit from being usable by anyone other than someone having been able to get into that subnet.

The next upside of such a control is that even if the T3 vulnerability was exploited, the ‘blast radius’ is constrained, as the network configuration will make it a lot harder to move to other servers as first they need to find away to see beyond the local network. This brings another philosophical change which doesn’t have to be difficult to achieve. We always look at security on the inbound traffic – but we should be just as observant about outbound paths, and have controls. One very contemporary aspect of this is to put gateways between applications or agents and LLMs. The focus is that credentials to external tools and services are only introduced beyond the sphere of the LLM(s). But we can also prevent the LLM from being hijacked into abusing tools (from the LLM view point it is an inbound security control). But we should treat all outbound data this way. Its the fastest way to detect and stop data egress.

It doesn’t need a chaos monkey but …

Many will have over the years heard about the development of the chaos monkey at Netflix by Greg Orzell which is a small app that can be unleashed and will try to tear everything up. While this maybe seen as rather extreme, the underlying message is once its secured, don’t assume it remains secure (controls can be accidentally removed). Put basic security probes into the environment – you can test non-destructively. Don’t put a procedure in place and let is rot on a shelf, if you have capacity – fail things over. The more these sorts of processes a run, the more it becomes ‘muscle memory’ and while early iterations will be painful, that pain and cost will be minor to when it happens for real.

It isn’t if, but when …

We all like to think these things won’t happen to us, and we’re prepared. But worldwide 1 in 5 will have cancer in their lifetime. Many cancers are treatable, and largely routine – because the medical profession have had to treat the problem over and over. We just have to see IT attacks in the same manner.

Data sources and reporting

1. CISA Known Exploited Vulnerabilities catalogue.
2. CVE monthly trends, including CISA additions — cve.tools.
3. VulnCheck: State of Exploitation 2026 (analysing 2025).
4. CIRCL Vulnerability-Lookup | GitHub Repository
5. CRACI CVE Publication Trends | CVE Program GitHub
6. VulnCheck: State of Exploitation, H1 2026.
7. VulnCheck: Expanding KEV, July 2025.
8. Verizon 2026 DBIR.
9. Google Threat Intelligence: 2025 zero-day review.
10. Edgescan report 2026