To view older blog posts, please visit the archives section.

What exactly is the CISA KEV catalog and why use it?

The KEV catalog is an initiative by CISA, the U.S. Cybersecurity and Infrastructure Security Agency, that aims to maintain a list of vulnerabilities that are known to be exploited in the wild. This helps vulnerability management teams prioritize high-impact vulnerabilities for their patching efforts. The KEV catalog has been criticized in the past. Some critics note that the catalog is incomplete and therefore can’t be used as a sole source of truth. While these limitations are real, the CISA KEV catalog remains a widely available source of information. It is also freely accessible. For this reason, and because this article is interested in general trends rather than complete exploitation coverage, the CISA KEV catalog has been used as the main source of information. The NVD database was used to retrieve CVE publication dates. All data presented through the article was retrieved by the author on June 6th, 2026.

The raw numbers

More vulnerabilities are being added to the KEV catalog shortly after being published. The raw monthly volume of recently published CVEs added to KEV within 30 days of publication shows a soft increasing trend over the last two years. This is shown in the following chart:

However, in the current situation where we’re seeing an explosion in the number of CVEs being published, relying solely on volume is dangerous and could lead to misguided conclusions. To see the actual picture, one needs to normalize the data against the number of CVEs being published.

Seeing past the raw additions

The volume of CVEs quickly added to KEV is increasing but so is the volume of CVEs being published. When looking at the percentage of vulnerabilities being added to the KEV catalog within 5 and 30 days of a CVE being published, the data presents a slightly different picture. In fact, the data suggests that we might be witnessing a very slight decrease in the percentage of CVEs being added to the KEV catalog. This is shown in the two charts below:

So what does this mean? The data does not give us certainty, but it does invite a few hypotheses. Among the possibilities, what we’re seeing could be an indication that, while more vulnerabilities are published, attackers may not yet have adapted to the volume we are facing. After all, even attackers have staffing problems. It could also mean that many published vulnerabilities do not offer the operational value attackers need for real-life exploitation. 

Attackers’ need for exploitation? What do you mean?

Many organized groups that possess offensive capabilities should be understood as functioning in a business-like fashion. These groups actively invest in the acquisition or development of their offensive capabilities, including exploits. Therefore, before engaging in any activities, they have to think, even informally, in terms of return on investment. Just like any other business. In their case, the elements in deciding whether or not to develop an exploit around a vulnerability can be multiple and varied. Here are a handful of examples:

• How widely adopted is a given vulnerable technology?

• How reusable would an exploit for a given vulnerability be?

• What are the patching habits of a typical target for a given technology?

• What would be the typical success rate for an exploit against a given vulnerability?

• How much time would developing an exploit for a vulnerability require?

• Can a lower impact vulnerability be used as part of an exploit chain?

Because of factors such as the ones presented above, many easily exploitable vulnerabilities may never be exploited by organized groups: some vulnerabilities are impractical and present an ROI that is simply too low. So where should your vulnerability management team focus and what can we learn from the available data?

What can we learn from this activity and how can we leverage the data?

Using AI, I’ve processed the information of all vulnerabilities published between January 2024 and May 2026 that were also added to the KEV catalog. While spot checks were made to ensure data quality, this should still be considered as approximate. The reason I did so was to illustrate clusters forming around targeted products and vulnerability families to better understand, based on historical KEV data rather than intuition alone, what could make a vulnerability attractive for an organized offensive group in a modern setting. First, let’s look at the vulnerability families cluster. The chart below shows the clusters:

As we can see from the graphic, certain types of vulnerabilities are much more common in the KEV listed vulnerabilities. Among these, memory safety, when all memory safety families are combined, is a strong outlier compared to any other vulnerability families. Excluding the combined memory safety family, here are the top 10 most represented vulnerability families in the KEV catalog:

1. Privilege escalation

2. Path traversal

3. OS command injection

4. Authentication bypass

5. Deserialization of untrusted data

6. Memory safety: use-after-free

7. Remote code execution / code execution

8. Memory safety: out-of-bounds write

9. Improper access control

10. Information disclosure

What many of these families have in common is their ability to either provide direct access to a system or to provide or alter information that could be used against the system either independently or as part of an exploit chain. It should also be noted that many “information disclosure” or “memory write” types of vulnerabilities would not score a 10 on a CVSS evaluation. Far from it in fact. Yet, these are present on this list. A future article will explore this further.

Now, as interesting as they can be, vulnerability families are nothing more than a single angle of this. Even more interesting, in the boundaries of the current article, is the clusters forming around the products that are represented in the KEV catalog. The chart below shows the clusters:

We can see that Microsoft Windows is the largest cluster here. Looking at the top 10 products (and almost everything further lower), you might be able to make a crucial observation. Here is the top 10 clusters for your consideration:

1. Microsoft Windows

2. Apple Multiple Products

3. Google Chromium V8

4. Linux Kernel

5. Palo Alto Networks PAN-OS

6. Synacor Zimbra Collaboration Suite (ZCS)

7. Ivanti Endpoint Manager (EPM)

8. Ivanti Endpoint Manager Mobile (EPMM)

9. Microsoft SharePoint

10. Qualcomm Multiple Chipsets

What should come out as your observation is that each of these is a market-ready packaged product or heavily used as part of a packaged product. This is important because this aligns perfectly with the first two elements on the ROI list I suggested earlier copied here as a reminder:

• How widely adopted is a given vulnerable technology?

  • Market ready products are often widely adopted;

• How reusable would an exploit for a given vulnerability be?

  • Market ready products generally present the same flaws in the same ways increasing the likelihood that exploit work can be reused across many targets.

Based on the observations made so far, I suggest that the potential ROI for single vulnerability exploitation, from an attacker standpoint, should be considered in the conduct of your patch management program. This may or may not already be reflected in EPSS. FIRST describes EPSS as a data-driven model built on hundreds of variables, but because the full weighting and internal decision process are not directly inspectable by practitioners, it is difficult to validate how much these attacker ROI factors are represented in the score. In any case, attackers’ ROI view of the world can certainly help vulnerability management teams better conceptualize why certain vulnerabilities gain more attention from their adversaries.

Conclusion

In the end, while CVE publication numbers are increasing, the potential AI-enabled storm of KEV additions has not yet materialized. This gives defenders much-needed time to prepare. In addition, the historical data shows that attackers have relatively strong interests in certain types of vulnerabilities and targeted products. This should become part of the prioritization conversation within vulnerability management teams. 

While this article did not explore much of the “in-house” development side of the issue, my next article will specifically focus on the issue of patch prioritization for in-house developed systems. Stay tuned!