1,680 entries, one certainty
CISA’s Known Exploited Vulnerabilities (KEV) database now contains nearly 1,680 entries. Each new entry means one thing and one thing only: this vulnerability is being actively exploited in the wild. It is not a score or a severity rating. It’s simply concrete proof that an attacker, somewhere, has already used this vulnerability to compromise a system. If your prioritization relies exclusively on theoretical scores, it’s time to rethink your approach.
KEV : definition and foundations
What is the KEV?
Known Exploited Vulnerabilities (KEV) is a catalog maintained by the U.S. government’s cybersecurity agency: the Cybersecurity and Infrastructure Security Agency (CISA). Its purpose is simple: to list vulnerabilities for which active exploitation has been confirmed.
Unlike traditional databases (such as the NVD), the KEV is based neither on technical severity (CVSS) nor on the likelihood of exploitation (EPSS). It relies on a binary criterion: the vulnerability has been confirmed to be exploited.
From who and to who?
CISA serves as the leading agency for cybersecurity in the United States. Its guidelines are particularly binding on U.S. government agencies (through Binding Operational Directives—BODs).
However, these guidelines have also been widely adopted by the private sector because CISA’s unique position gives it a comprehensive view of attacks targeting the United States.
How and how often should one check the KEV?
The KEV is publicly available in various formats:
This feed contains key information for assessing the exploitation of a vulnerability. The mere presence of a vulnerability in the catalog indicates that it has been or is being exploited—or, for example, that it is being exploited by ransomware groups.
It is updated daily based on incidents observed by CISA. U.S. government agencies are also required to carry out remediation activities by deadlines set by the agency. These deadlines also serve as a good indicator of the level of urgency associated with the vulnerability.
In particular, BOD26-04 (see our article on this topic) provides a quick way to understand the agency’s expected stance toward U.S. government agencies and, therefore, the appropriate response even for private companies.
KEV vs CVSS vs EPSS: three metrics, one source of truth
Many security, infrastructure, and SecOps teams still use the basic CVSS (Common Vulnerability Scoring System) score to prioritize their vulnerabilities. This is a mistake that has serious consequences for the effectiveness of vulnerability management processes.
CVSS serves a purpose: to assess the intrinsic severity of a vulnerability. However, it was never intended to prioritize vulnerabilities. It is therefore just one indicator among many that helps assess how a vulnerability management team will respond.
Although more grounded in real-world conditions, the EPSS (Exploit Probability Scoring System) is also an assessment and, as such, is imprecise. It is, however, a good indicator for anticipating the future exploitation of a vulnerability.
Of these three indicators, only the KEV reflects real-world conditions. It also has virtually no false positives. It does, however, have the drawback of being reactive, unlike the other two metrics, which enable a proactive approach.
Why is the KEV more important than the CVSS for prioritization?
The CVSS, as presented in most sources, does not take into account the reality or likelihood of exploitation. It primarily considers the intrinsic properties of the vulnerability: what it allows a malicious actor to do, under what conditions, and with what impact.
Thus, a vulnerability may have a very significant impact... but may not be exploited at all.
Since the KEV reflects real-world exploitation, there is a lack of correlation between the CVSS and the catalog. A high CVSS score does not guarantee inclusion in the KEV. And the reverse is also true: inclusion in the KEV is not an indicator of a high CVSS score.
By evaluating the combinations of CVSS and KEV, we can conclude that:
- A vulnerability may have a maximum score without being targeted and therefore not appear in the KEV;
- A vulnerability with an average score but one that is widely exploited will appear in the KEV. Threat actors can gain significant advantage even with low-severity vulnerabilities (to advance the attack further or because the exploitation context makes it more attractive);
- The KEV is real-world proof: If a CVE is in the KEV, it means an attacker has already successfully exploited it. The score is irrelevant.
The KEV is not a silver bullet
KEV, like the CVE system, is a U.S.-developed tool and has been widely adopted worldwide as a de facto standard. It is therefore a reliable and proven tool.
However, its limitations must be taken into account before considering its integration into vulnerability management processes.
The KEV does not cover everything
CISA focuses on vulnerabilities exploited against U.S. infrastructure. Certain targeted attacks (for example, against French companies) may not be included. This is especially true for countries outside the Western sphere.
It is also important to consider that, despite its dominant position, CISA is not an all-knowing or fully transparent agency. Furthermore, it is aligned with U.S. interests, which inevitably skews the catalog’s editorial stance.
Therefore, the absence of a vulnerability in the KEV should never be considered equivalent to the absence of exploitation. Doing so will create numerous false negatives that will have an equally significant impact.
This is where other metrics come into play to inform decision-making. It is also important to use a variety of sources:
- Official sources: Sources exist outside the U.S. sphere, particularly at the national agency level. In France, the National Agency for Information System Security (ANSSI) publishes CERT-FR alerts. In Germany, the Federal Office for Information Security (BSI) also has its own system. There is even one at the European Union level;
- News sources: Numerous specialized online journals provide context on specific events;
- Weak signals: Although more difficult to detect due to their diversity and the need to assess their reliability, they enable a more responsive approach by evaluating vulnerabilities at the source. These signals may come from forums frequented by malicious actors or even from discussions among development teams.
Geographical skew in the announced patch delays
Even though cyberattacks on the Internet are generally targeted by opposing blocs (Western, Asian, etc.), each country has its own specific characteristics. Thus, the timelines announced by CISA are based on U.S. constraints and biases.
A vulnerability may be added to the KEV long before Europe is affected, or conversely, it may first appear in Europe and not reach the United States until later.
The required response time therefore varies depending on the situation. It is important to stay informed about local alerts and, in some cases, even sector-specific alerts.
Old CVEs added later
The KEV is a catalog that is constantly updated, though not necessarily immediately following the disclosure of a vulnerability. Some entries are added well after the vulnerability is disclosed, typically following a specific news story related to it.
For example, CVE-2019-1068 (affecting Microsoft SQL Server) was added to the KEV on August 26, 2026—seven years after its disclosure. The reason is simple: ransomware groups exploited it on a massive scale in 2026.
The consequences can be significant if you decided at the time to accept the risk and close the vulnerability fix with no possibility of reversing the decision.
In your vulnerability management process, you should never remove a vulnerability from the inventory. Instead, archive it, which allows you to revert the decision in the event of a new incident.
Open source software and shared component: A blind angle
The KEV focuses on commercial products (Microsoft, Adobe, Cisco, etc.). Vulnerabilities in open-source libraries (Log4j, OpenSSL, Spring, etc.) appear less frequently in the KEV, even though they are also sources of actively exploited vulnerabilities.
What is expected by NIS2
The NIS2 Directive (effective throughout the European Union as of October 2024) requires operators of essential services (OES) and major digital service providers to:
- Actively monitor vulnerabilities;
- Apply patches within a reasonable timeframe;
- Report significant incidents.
This means that tracking additions to the KEV is a form of active vulnerability monitoring. However, this monitoring should not be blind: keeping track of recommendations from one’s national information security authority is also essential.
The deadlines recommended by the KEV are not, in principle, binding in terms of what is considered a reasonable timeframe. That said, NIS2 generally requires a response within 72 hours for critical vulnerabilities, which is consistent with the BODs imposed on government agencies by CISA for the same category.
Take action
The KEV isn’t just another list. It’s the most reliable indicator that a vulnerability is active in the wild. But its true power lies in how it intersects with your infrastructure.
The KEV and other sources are natively integrated into our VulnPilot solution, directly influencing the priority assigned by our vulnerability intelligence solution.
You then automatically receive, in a timely manner, the actions to be taken as soon as possible, taking into account the actual situation on the ground.