Reducing the Significant Risk of Known Exploited Vulnerabilities

For the benefit of the cybersecurity community and network defenders—and to help every organization better manage vulnerabilities and keep pace with threat activity—CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild: the Known Exploited Vulnerability (KEV) catalog. CISA strongly recommends all organizations review and monitor the KEV catalog and prioritize remediation of the listed vulnerabilities to reduce the likelihood of compromise by known threat actors.

All federal civilian executive branch (FCEB) agencies are required to remediate vulnerabilities in the KEV catalog within prescribed timeframes under Binding Operational Directive (BOD) 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities.  Although not bound by BOD 22-01, every organization, including those in state, local, tribal, and territorial (SLTT) governments and private industry can significantly strengthen their security and resilience posture by prioritizing the remediation of the vulnerabilities listed in the KEV catalog as well. CISA strongly recommends all stakeholders include a requirement to immediately address KEV catalog vulnerabilities as part of their vulnerability management plan. Doing so will build collective resilience across the cybersecurity community.

How should organizations use the KEV catalog?

The KEV catalog sends a clear message to all organizations to prioritize remediation efforts on the subset of vulnerabilities that are causing immediate harm based on adversary activity. Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework. Vulnerability management frameworks—such as the Stakeholder-Specific Vulnerability Categorization (SSVC) model—consider a vulnerability's exploitation status and the KEV catalog serves as the authoritative repository of that information. Organizations should also consider using automated vulnerability and patch management tools that automatically incorporate and flag or prioritize KEV vulnerabilities. 

The following sections detail the criteria behind each of the three thresholds for KEV catalog updates, which are:

  • The vulnerability has an assigned Common Vulnerabilities and Exposures (CVE) ID.
  • There is reliable evidence that the vulnerability has been actively exploited in the wild.
  • There is a clear remediation action for the vulnerability, such as a vendor-provided update.

Criteria #1 - Assigned CVE ID

The first criteria for adding a vulnerability to the KEV catalog is the assignment of a CVE ID. A CVE ID—also known as CVE identifier, CVE record, CVE name, CVE number, and CVE—is a unique, common identifier for a publicly known cybersecurity vulnerability. (See https://www.cve.org/ResourcesSupport/FAQs.)

The CVE Program is sponsored by CISA and run by a non-profit, federally funded, research and development center (FFRDC), which is operated by The MITRE Corporation. The mission of the CVE Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. (See https://www.cve.org/About/Overview.) 

The process of obtaining a CVE ID begins with the discovery of a potential cybersecurity vulnerability. The information is then assigned a CVE ID by a CVE Numbering Authority (CNA). (See https://www.cve.org/About/Process#CVERecordLifecycle.) A CNA is an organization authorized to assign and populate CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope. Becoming a CNA is voluntary. A CNA can be a software vendor, open-source project, coordination center, bug bounty service provider, or research group. (See https://www.cve.org/ProgramOrganization/CNAs.) 

After the CNA creates the CVE record, including a description and references, MITRE posts it on the CVE website. (See https://www.cve.org/About/Process#CVERecordLifecycle.) 

The MITRE CVE® List website https://cve.mitre.org/cve and the National Vulnerability Database (NVD) https://nvd.nist.gov/ website, maintained by the National Institute of Standards and Technology (NIST), provide a running list of all assigned CVEs. The NVD is synchronized with CVE such that any updates to CVE appear immediately on the NVD. It augments information provided by CVE List with a database of security checklist references, security related software flaws, misconfigurations, product names, impact metrics, and a search engine. (See https://nvd.nist.gov/general/FAQ-Sections/General-FAQs.)  

According to https://www.cve.org/About/Process#CVERecordLifecycle, a CVE entry can be in one of three states:

  1. Reserved: The initial state for a CVE Record; when the associated CVE ID is Reserved by a CNA. If the CVE record shows as reserved, visitors/users can submit a CVE Request to MITRE via https://cveform.mitre.org/ to request the CVE record be published. In the form, select ”Request Type” as “Other” and ”Type of comment” as “Issue.”   
  2. Published: When a CNA populates the data associated with a CVE ID as a CVE Record, the state of the CVE Record is Published. The associated data must contain an identification number (CVE ID), a prose description, and at least one public reference.
  3. Rejected: If the CVE ID and associated CVE Record should no longer be used, the CVE Record is placed in the Rejected state. A Rejected CVE Record remains on the CVE List so that users can know when it is invalid.

Criteria #2 - Active Exploitation

The term “exploitable” refers to how easily an attacker can take advantage of a vulnerability. It evaluates various aspects such as: availability of a public proof-of-concept (PoC), network accessibility, unprivileged access, wormability, and skill-level needed to carry out the exploit. Wormability refers to a cyberattack that can spread from one machine to another without user interaction. An analysis of a vulnerability's exploitability can assist in determining the severity of the vulnerability. 

However, a vulnerability's exploitability is not considered as criteria for inclusion in the KEV catalog. Rather, the main criteria for KEV catalog inclusion, is whether the vulnerability has been exploited or is under active exploitation. These two terms refer to the use of malicious code by an individual to take advantage of a vulnerability. In reference to the KEV catalog, active exploitation and exploited are synonymous.

A vulnerability under active exploitation is one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner. 

Active exploitation, in reference to the KEV catalog, also includes attempted exploitation and successful exploitation. 

  • Attempted exploitation occurs when an attacker executes code on a target system, but the code does not execute due to the system not being vulnerable, or the system being a honeypot, etc. A honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Successful malicious code execution on a honeypot is considered attempted exploitation because the attacker does not obtain actual target information.
  • Successful exploitation occurs when an attacker successfully exploits vulnerable code on a target system, allowing them to perform additional, unauthorized actions on that system or network.

The two key takeaways for active exploitation are: the intent of the actor is to succeed in exploitation and the attack(s) occurred in real time, or “in the wild.” 

Events that do not constitute as active exploitation, in relation to the KEV catalog, include:

  • Scanning
  • Security research of an exploit
  • Proof of Concept (PoC)

PoC is the code for a vulnerability that, when executed, would allow for exploitation. Exchange of PoC between security researchers and vendors occurs regularly to demonstrate how the vulnerability can be exploited and to assist vendors in developing a patch for the vulnerability. Making PoC publicly available can increase the likelihood of an attacker exploiting the vulnerability in the wild. However, the public availability of a PoC does not automatically indicate the vulnerability has been or will be exploited. Having a publicly available PoC is not a requirement for a vulnerability to be included in the KEV catalog.

Note: Organizations or individuals with information about an exploited vulnerability not currently listed on the KEV are encouraged to contact us at vulnerability@cisa.dhs.gov.

Criteria #3 - Clear Remediation Guidance

CISA adds known exploited vulnerabilities to the catalog when there is a clear action for the affected organization to take. The remediation action referenced in BOD 22-01 requires federal civilian executive branch (FCEB) agencies to take the following actions for all vulnerabilities in the KEV, and CISA strongly encourages all organizations to do the same:

  • Apply updates per vendor instructions. There is an update available from the security vendor, and users should apply it.
  • Remove from agency networks if the impacted product is end-of-life or cannot be updated otherwise. 

Mitigations are temporary solutions users can implement to prevent a vulnerability's exploitation. For an example, see the PDF below on Mitigating Attacks Against Uninterruptible Power Supply Devices, which provides best practice guidance to prevent exploitation of uninterruptible power supply (UPS) devices.

Mitigating Vulnerabilities Affecting Uninterruptible Power Supply Devices(PDF, 206.46 KB )

A workaround involves implementing manual changes to an affected product to protect a vulnerable system from exploitation until the vendor releases a formal security patch. It is a best practice for users to transition from a workaround to an official patch, when available. However, implementing a workaround is recommend as opposed to leaving a product vulnerable.

Note: CISA relies on stakeholder feedback to improve its services to the cybersecurity community. To provide feedback on the KEV catalog criteria and process, email CISA.JCDC@CISA.DHS.GOV.