www.cisa.gov
Open in
urlscan Pro
2a02:26f0:3400:2b8::447a
Public Scan
URL:
https://www.cisa.gov/known-exploited-vulnerabilities
Submission: On June 13 via api from TR — Scanned from DE
Submission: On June 13 via api from TR — Scanned from DE
Form analysis 2 forms found in the DOM
<form class="gsc-search-box gsc-search-box-tools" accept-charset="utf-8">
<table cellspacing="0" cellpadding="0" role="presentation" class="gsc-search-box">
<tbody>
<tr>
<td class="gsc-input">
<div class="gsc-input-box" id="gsc-iw-id1">
<table cellspacing="0" cellpadding="0" role="presentation" id="gs_id50" class="gstl_50 gsc-input" style="width: 100%; padding: 0px;">
<tbody>
<tr>
<td id="gs_tti50" class="gsib_a"><input autocomplete="off" type="text" size="10" class="gsc-input" name="search" title="search" aria-label="search" id="gsc-i-id1" dir="ltr" spellcheck="false"
style="width: 100%; padding: 0px; border: none; margin: 0px; height: auto; outline: none;"></td>
<td class="gsib_b">
<div class="gsst_b" id="gs_st50" dir="ltr"><a class="gsst_a" href="javascript:void(0)" title="Clear search box" role="button" style="display: none;"><span class="gscb_a" id="gs_cb50" aria-hidden="true">×</span></a></div>
</td>
</tr>
</tbody>
</table>
</div>
</td>
<td class="gsc-search-button"><button class="gsc-search-button gsc-search-button-v2"><svg width="13" height="13" viewBox="0 0 13 13">
<title>search</title>
<path
d="m4.8495 7.8226c0.82666 0 1.5262-0.29146 2.0985-0.87438 0.57232-0.58292 0.86378-1.2877 0.87438-2.1144 0.010599-0.82666-0.28086-1.5262-0.87438-2.0985-0.59352-0.57232-1.293-0.86378-2.0985-0.87438-0.8055-0.010599-1.5103 0.28086-2.1144 0.87438-0.60414 0.59352-0.8956 1.293-0.87438 2.0985 0.021197 0.8055 0.31266 1.5103 0.87438 2.1144 0.56172 0.60414 1.2665 0.8956 2.1144 0.87438zm4.4695 0.2115 3.681 3.6819-1.259 1.284-3.6817-3.7 0.0019784-0.69479-0.090043-0.098846c-0.87973 0.76087-1.92 1.1413-3.1207 1.1413-1.3553 0-2.5025-0.46363-3.4417-1.3909s-1.4088-2.0686-1.4088-3.4239c0-1.3553 0.4696-2.4966 1.4088-3.4239 0.9392-0.92727 2.0864-1.3969 3.4417-1.4088 1.3553-0.011889 2.4906 0.45771 3.406 1.4088 0.9154 0.95107 1.379 2.0924 1.3909 3.4239 0 1.2126-0.38043 2.2588-1.1413 3.1385l0.098834 0.090049z">
</path>
</svg></button></td>
<td class="gsc-clear-button">
<div class="gsc-clear-button" title="clear results"> </div>
</td>
</tr>
</tbody>
</table>
</form><form class="gsc-search-box gsc-search-box-tools" accept-charset="utf-8">
<table cellspacing="0" cellpadding="0" role="presentation" class="gsc-search-box">
<tbody>
<tr>
<td class="gsc-input">
<div class="gsc-input-box" id="gsc-iw-id2">
<table cellspacing="0" cellpadding="0" role="presentation" id="gs_id51" class="gstl_51 gsc-input" style="width: 100%; padding: 0px;">
<tbody>
<tr>
<td id="gs_tti51" class="gsib_a"><input autocomplete="off" type="text" size="10" class="gsc-input" name="search" title="search" aria-label="search" id="gsc-i-id2" dir="ltr" spellcheck="false"
style="width: 100%; padding: 0px; border: none; margin: 0px; height: auto; outline: none;"></td>
<td class="gsib_b">
<div class="gsst_b" id="gs_st51" dir="ltr"><a class="gsst_a" href="javascript:void(0)" title="Clear search box" role="button" style="display: none;"><span class="gscb_a" id="gs_cb51" aria-hidden="true">×</span></a></div>
</td>
</tr>
</tbody>
</table>
</div>
</td>
<td class="gsc-search-button"><button class="gsc-search-button gsc-search-button-v2"><svg width="13" height="13" viewBox="0 0 13 13">
<title>search</title>
<path
d="m4.8495 7.8226c0.82666 0 1.5262-0.29146 2.0985-0.87438 0.57232-0.58292 0.86378-1.2877 0.87438-2.1144 0.010599-0.82666-0.28086-1.5262-0.87438-2.0985-0.59352-0.57232-1.293-0.86378-2.0985-0.87438-0.8055-0.010599-1.5103 0.28086-2.1144 0.87438-0.60414 0.59352-0.8956 1.293-0.87438 2.0985 0.021197 0.8055 0.31266 1.5103 0.87438 2.1144 0.56172 0.60414 1.2665 0.8956 2.1144 0.87438zm4.4695 0.2115 3.681 3.6819-1.259 1.284-3.6817-3.7 0.0019784-0.69479-0.090043-0.098846c-0.87973 0.76087-1.92 1.1413-3.1207 1.1413-1.3553 0-2.5025-0.46363-3.4417-1.3909s-1.4088-2.0686-1.4088-3.4239c0-1.3553 0.4696-2.4966 1.4088-3.4239 0.9392-0.92727 2.0864-1.3969 3.4417-1.4088 1.3553-0.011889 2.4906 0.45771 3.406 1.4088 0.9154 0.95107 1.379 2.0924 1.3909 3.4239 0 1.2126-0.38043 2.2588-1.1413 3.1385l0.098834 0.090049z">
</path>
</svg></button></td>
<td class="gsc-clear-button">
<div class="gsc-clear-button" title="clear results"> </div>
</td>
</tr>
</tbody>
</table>
</form>Text Content
Skip to main content
An official website of the United States government
Here’s how you know
Here’s how you know
Official websites use .gov
A .gov website belongs to an official government organization in the United
States.
Secure .gov websites use HTTPS
A lock (LockA locked padlock) or https:// means you’ve safely connected to the
.gov website. Share sensitive information only on official, secure websites.
Cybersecurity & Infrastructure Security Agency
America's Cyber Defense Agency
Search
×
search
Menu
Close
×
search
* Topics
Topics
Cybersecurity Best Practices
Cyber Threats and Advisories
Critical Infrastructure Security and Resilience
Election Security
Emergency Communications
Industrial Control Systems
Information and Communications Technology Supply Chain Security
Partnerships and Collaboration
Physical Security
Risk Management
How can we help?
GovernmentEducational InstitutionsIndustryState, Local, Tribal, and
TerritorialIndividuals and FamiliesSmall and Medium BusinessesFind Help
Locally
* Spotlight
* Resources & Tools
Resources & Tools
All Resources & Tools
Services
Programs
Resources
Training
Groups
* News & Events
News & Events
News
Events
Cybersecurity Alerts & Advisories
Directives
Request a CISA Speaker
Congressional Testimony
* Careers
Careers
Benefits & Perks
HireVue Applicant Reasonable Accommodations Process
Hiring
Resume & Application Tips
Students & Recent Graduates
Veteran and Military Spouses
Work @ CISA
* About
About
Culture
Divisions & Offices
Regions
Leadership
Doing Business with CISA
Contact Us
Site Links
Reporting Employee and Contractor Misconduct
CISA GitHub
Report a Cyber Issue
America's Cyber Defense Agency
Breadcrumb
1. Home
Share:
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(link is external)—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. Examples of such tools include CISA's cyber
hygiene services, Palo Alto Networks Cortex, Tenable Nessus, Runecast, Qualys
VMDR, Wiz, Rapid7 InsightVM, and Rapid7 Nexpose. Organizations with additional
tools that are incorporating the KEV vulnerabilities can be added to this list
by emailing CISA.JCDC@CISA.DHS.GOV(link sends email).
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(link
is external).)
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(link is external).)
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(link is external).) 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(link is external).)
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(link is external).)
The MITRE CVE® List website https://cve.mitre.org/cve(link is external) 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(link is
external), 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/(link is
external) 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(link sends email).
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(link sends email).
* Federal Government
* Industry
* Small and Medium Businesses
* State, Local, Tribal, and Territorial Government
* Cybersecurity Best Practices
* Cyber Threats and Advisories
Return to top
* Topics
* Spotlight
* Resources & Tools
* News & Events
* Careers
* About
Cybersecurity & Infrastructure Security Agency
* Facebook
* Twitter
* LinkedIn
* YouTube
* Instagram
* RSS
CISA Central 888-282-0870 Central@cisa.dhs.gov(link sends email)
DHS Seal
CISA.gov
An official website of the U.S. Department of Homeland Security
* About CISA
* Accessibility
* Budget and Performance
* DHS.gov
* FOIA Requests
* No FEAR Act
* Office of Inspector General
* Privacy Policy
* Subscribe
* The White House
* USA.gov
* Website Feedback