Go back

Prioritizing CISA Known Exploited Vulnerabilities

Jacob Baines@Junior_Baines

The CISA Known Exploited Vulnerabilities (KEV) Catalog tracks vulnerabilities that have been exploited in the wild, and it currently has more than 850 entries. New entries are added to the Catalog at a regular clip, but as the Catalog continues to grow, it's become increasingly difficult for those not bound to the Binding Operational Directive 22-01 to determine the significance of each KEV entry and how they should be prioritized for remediation.

In this blog, we'll tackle the KEV prioritization problem head-on. We'll identify a small subset of KEV entries that should be remediated now because they pose the highest risk. Then we'll identify another group of high risk KEV entries that should be remediated next. We'll achieve this prioritization by identifying who is exploiting these vulnerabilities.

Focusing on Initial Access

Local vulnerabilities make up 23% of the KEV Catalog. Attackers exploit local vulnerabilities to escalate privileges or trigger phishing payloads. But these vulnerabilities are only useful if the attacker has already breached a network or tricked a user into interacting with malicious content.

Far more concerning are remote vulnerabilities that don't require authentication or user interaction. When used against public-facing systems, these kind of vulnerabilities are great initial access vectors. Attackers that exploit public-facing systems are often able to use the exploited system as a beachhead into the victim's internal network. Obviously, that's a great position for an attacker and very dangerous situation for the victim. And given that high value, it's unsurprising that initial access vulnerabilities make up about 37% of the KEV Catalog.

CISA KEV Catalog Sorted By Vulnerability Type

These types of public-facing initial access vulnerabilities can also be exploited at scale. That's especially useful when the attacker's business model relies on volume. Recent examples of mass exploitation of initial access vulnerabilities include Confluence's CVE-2022-26134, log4shell, and the ProxyShell vulnerabilities.

So it's clear that internet accessible vulnerabilities pose a serious risk. A risk that exceeds other attack vectors. Both phishing and social engineering also pose significant risk, but those vectors rely on human behavior and have a slew of other mitigations outside of the vulnerability management process. As such, prioritizing the remediation of initial access vulnerabilities, over all others, is a reasonable method to reduce risk via vulnerability management.

Focusing on initial access vulnerabilities also allows us to de-prioritize more than 60% of the KEV Catalog. That's a good start, but still an unwieldy number of issues. Let's reduce the list even further!

Who and Why Matters

Treating every exploited-in-the-wild vulnerability as if they represent the same amount of risk is obviously incorrect. Knowing who is doing the exploitation and why are crucial in determining that risk. While the KEV Catalog doesn't provide these details, the VulnCheck Vulnerability Intelligence Feed does. Based on our intelligence, we can sort the KEV Catalog's initial access vulnerabilities into six groups, descending in priority:

  1. Vulnerabilities used by ransomware
  2. Vulnerabilities used by advanced threat groups
  3. Vulnerabilities used by botnets
  4. Vulnerabilities with weaponized exploits but no publicly reported exploitation
  5. Vulnerabilities with proof of concept exploits but no publicly reported exploitation
  6. Vulnerabilities with neither an exploit or publicly reported exploitation details

The preceding list attempts to sort the vulnerabilities by risk. Ransomware vulnerabilities pose the most risk because exploitation can rapidly halt business operations, cost thousands to millions of dollar, and even destroy the victim's business. Remediating vulnerabilities known to be used by ransomware should be a vulnerability management program's top priority.

Vulnerabilities used by advanced threat groups and botnets pose the next highest risk because they can result in data loss, intellectual property loss, and significant reputational harm. Ideally, these vulnerabilities would be prioritized next.

The remaining vulnerabilities only pose a high potential risk. Many of these vulnerabilities have public exploits, but have no reliable reporting tying them to ransomware, advanced threat groups, or botnets. Their inclusion in the KEV Catalog does indicate they may have been used somewhere, but the lack of further details implies a very small scale exploitation or low impact results for the attacker. These vulnerabilities shouldn't necessarily be ignored, but they don't rank compared to vulnerabilities that are known to be impactful.

The Breakdown


Breaking down the initial access vulnerabilities in the KEV Catalog and sorting them into the various groups mentioned in the previous section results in the following chart:

CISA KEV Initial Access Vulnerabilities Sorted By Highest Risk

The graph shows that the immediate priority, ransomware vulnerabilities, only make up 34% of the KEV Catalog Initial Access vulnerabilities. That's about 100 vulnerabilities. A significant reduction from the more than 850 we started with. But, some of the 100 vulnerabilities are quite old, so we looked at further reducing this number based on age.

Ransomware Vulnerabilities by Year

However, we quickly found most of them are still relevant. Take for example, the oldest vulnerability in the list, JBoss's CVE-2010-0738. Although this vulnerability has been public for over a decade, has been presented in talks, and has a quite a few public exploits, we can still find likely vulnerable targets on both Google and Shodan. For whatever reason, it seems like a lot of these 100 vulnerabilities are hanging around the internet still, which means we have to keep them in our prioritization list.


Advanced Threat Groups and Botnets

Vulnerabilities used by advanced threat groups and botnets represent 16% and 15% of the KEV Catalog initial access vulnerabilities. Interestingly, the vulnerabilities in these category could typically be used by ransomware crews, but, for whatever reason, simply aren't. For example, CVE-2022-1388 is a widely exploited vulnerability affecting F5 BigIP, but we have no intelligence suggesting it was abused by ransomware (at the time of writing).

The botnet category is more likely to contain IoT-based vulnerabilities such as CVE-2022-26258 and CVE-2019-3929. Again, these vulnerabilities can provide access into victim networks but they seem to be used mostly by botnets like Mirai variants like Moobot.

Remediating ransomware vulnerabilities is important, but it should be kept in mind that many of the vulnerabilities in this category can be picked up by a ransomware crews at any time. And, of course, as discussed earlier, advanced threat groups and botnets also pose a significant risk. This category is a great "next" if your vulnerability management program has caught up on all known ransomware vectors.

Exploits Exists

Vulnerabilities used by ransomware, advanced threat groups, and botnets pose a real and immediate risk, but those vulnerabilities only make up about half of the initial access vulnerabilities in the KEV Catalog. The remaining vulnerabilities are only potential risks because there is no reliable public reporting about their use in the wild. The potential risk is variable though. For example, CVE-2020-4427 has a fully weaponized public exploit in the Metasploit Framework. Metasploit is an open source advanced exploitation tool, and anyone can use it. There is nothing stopping attackers from using the Metasploit module for CVE-2020-4427 on public-facing server. But there is no reporting that any group has. So that's a clear high potential risk, but it doesn't reach the level of a known high risk.

Even lower on our risk assessment are vulnerabilities that only have proof of concept exploits. For example, CVE-2021-40870 has a handful of public proof of concept exploits, including a curl-based exploit published by the vulnerability discoverer. Again, anyone can use these exploits but they lack the true weaponization we expect from real real-world exploit kits. An attacker would need to take on some work in order to integrate the proof of concept exploits into their tool belt. A such, these are more of a medium potential risk and are far less likely to see any type of exploitation at scale.

No Exploit. No Reliable Reporting.

The final grouping of vulnerabilities in our prioritization list are the vulnerabilities that don't have a known exploit and there's no public information regarding use in-the-wild. While KEV Catalog entries should always be taken seriously, the lack of contextualization around these vulnerabilities makes them very difficult to prioritize. Given the lack of details, it's assumed these vulnerabilities are either not being actively exploited or they were used in targeted attacks against a minimal amount of targets.

An example of an entry in this group is CVE-2021-37415, affecting ManageEngine ServiceDesk Plus. While ManageEngine software is certainly familiar to a wide array of attackers, this particular issue has almost no associated information. Keeping ManageEngine software up to date is obviously a good thing, but it shouldn't take precedence over vulnerabilities that we know are being exploited.


The CISA KEV Catalog contains hundreds of vulnerabilities that pose serious risk. But the Catalog lacks prioritization and, as it continues to grow, becomes increasingly unwieldy for security practitioners to use for remediation purposes. In this blog, we were able to identify approximately 10% of the KEV Catalog vulnerabilities as requiring immediate remediation, a number that is far more manageable for practitioners. We also identified an additional 16% of vulnerabilities that should be considered as the next vulnerabilities to remediate. We were able to achieve using vulnerability intelligence to determine who and why these vulnerabilities are being exploited.

About the Data

The data presented in this blog was produced using the VulnCheck Vulnerability Intelligence Feed. The data was compiled on November 14, 2022.