CISA KEV Catalog: The Federal Government’s Definitive List of Actively Exploited Vulnerabilities

In November 2021, the Cybersecurity and Infrastructure Security Agency published the first version of its Known Exploited Vulnerabilities catalog — 287 CVEs that federal analysts had confirmed were being actively weaponized in the wild. Within two years the catalog surpassed 1,000 entries. Today it is the closest thing the federal government has to a minimal, mandatory patch list: under Binding Operational Directive 22-01, every civilian executive branch agency must remediate KEV entries on a defined schedule or explain why they cannot. For the private sector, the catalog is non-binding but carries enormous weight as a curated signal that cuts through the noise of thousands of CVEs published each year.

This article covers what the KEV catalog contains field by field, the three criteria CISA uses to decide what goes on the list, how to download the catalog as JSON or CSV, the catalog's growth since launch, the top vendors by entry count, how KEV differs fundamentally from CVSS severity scoring, the Exploit Prediction Scoring System as a complementary resource, a Python snippet for joining the KEV JSON to NVD CVE data for CVSS enrichment, and how security teams use KEV to impose triage discipline in environments where thousands of vulnerabilities compete for patch resources.

What the KEV catalog contains

Each entry in the catalog is a JSON object (or a row in the CSV export) with a fixed set of fields. Understanding the schema is important because the fields encode specific policy meaning, not just descriptive metadata.

• cveID — the CVE identifier assigned by MITRE. Every entry must have one; CISA does not add vulnerabilities to the KEV without a CVE ID, which anchors the entry to the broader vulnerability ecosystem maintained by NVD, vendor advisories, and scanner databases.
• vendorProject — the name of the software vendor or open-source project affected. “Microsoft” is the most common value in the catalog, reflecting the scale of Microsoft's footprint in enterprise environments and the corresponding attacker attention.
• product — the specific product or component within the vendor's portfolio. Entries can be granular (“Internet Explorer” rather than just “Windows”) when the vulnerability is product-specific.
• vulnerabilityName — a short human-readable name for the vulnerability, typically derived from the vendor advisory or CVE description. This field is CISA's own naming and does not necessarily match the NVD description verbatim.
• dateAdded — the ISO 8601 date on which CISA added the entry to the catalog. This is not the date the vulnerability was first disclosed (the CVE publication date) and not the date exploitation was first observed — it is the date CISA made a determination to list it. The gap between a CVE's initial NVD publication and its KEV listing date is analytically useful: it measures how long it took CISA to act on exploitation evidence.
• shortDescription — a brief technical description of the vulnerability class: SQL injection, buffer overflow, use-after-free, deserialization of untrusted data, improper authentication, and so on. The description is concise, typically one to two sentences.
• requiredAction — the remediation instruction CISA issues. In most cases this is “Apply updates per vendor instructions,” but for some legacy or end-of-life products where no patch exists, CISA instead directs agencies to “Discontinue use of the product if mitigations are unavailable.” That instruction — stop using a product — is rare but significant when it appears.
• dueDate — the deadline by which federal civilian agencies must complete the required action. This is the operationally critical field for BOD 22-01 compliance. For entries added to the catalog after the initial November 2021 release, the due date is typically 14 calendar days from the dateAdded for vulnerabilities assessed as posing immediate risk, and up to six months for those assessed as lower immediate risk. The exact deadline is set by CISA at the time of listing.
• notes — an optional free-text field used for clarifications, links to vendor advisories, or caveats about specific affected versions. Many entries leave this blank; high-profile entries referencing specific threat actor campaigns sometimes include links to CISA alerts or joint advisories.

How CISA decides what goes on the list

CISA has published explicit criteria for KEV inclusion. A vulnerability must satisfy all three simultaneously:

1. It has an assigned CVE ID. Without a CVE, CISA cannot create a stable, cross-referenced catalog entry that scanner vendors, patch management platforms, and government agencies can act on consistently. Vulnerabilities discovered in the wild before a CVE is assigned may be tracked internally but will not appear in the public catalog until a CVE exists.
2. There is credible evidence of active exploitation in the wild. This is the defining criterion. “Active exploitation” means CISA has assessed that threat actors are currently using the vulnerability in real attacks against real targets — not proof-of-concept research code, not theoretical attack chains, not demonstration exploits published by security researchers. CISA draws on its own threat intelligence, reporting from CISA sectors, information shared by vendors and security companies, and open-source threat intelligence.
3. Clear guidance for remediation exists. If there is no vendor patch, no documented workaround, and no guidance that organizations can act on, CISA will not add the entry — the directive to remediate would be meaningless. This criterion occasionally delays listing for zero-days where the vendor has not yet released a patch. CISA has listed some entries with “Discontinue use” as the required action when patch guidance is unavailable for a legacy product, but this is the exception.

Critically, CVSS score is not a criterion. A CVSS 5.5 vulnerability that is being actively deployed in ransomware campaigns will be added to the KEV. A CVSS 9.8 critical vulnerability with no known real-world exploitation will not be. This deliberate design choice is the most important thing to understand about what the KEV is for.

How to access the catalog

The catalog is published at https://www.cisa.gov/known-exploited-vulnerabilities-catalog and available in two machine-readable formats. Both are updated on a rolling basis — typically within hours of CISA adding or modifying an entry.

The JSON feed is at https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. It is a single file containing all current entries, a catalog version string, and a dateReleased timestamp. The JSON structure is stable and well-suited to automated ingestion. CISA does not publish a changelog endpoint, so automated systems that want to detect additions typically diff the dateAdded field against a previously cached version of the catalog.

The CSV export is available from the same catalog page. It contains the same fields as the JSON representation in a flat tabular format suitable for direct loading into spreadsheet tools or pandas. For one-off analysis the CSV is convenient; for automated monitoring the JSON is preferable because it includes the catalog version metadata.

Catalog growth since launch

CISA launched the KEV catalog on November 3, 2021 with an initial batch of 287 entries. That first batch was not 287 newly discovered exploited vulnerabilities — it was a retrospective listing of CVEs that CISA had already determined were being actively exploited, some of them dating back years. CVE-2021-22005, a critical VMware vCenter Server arbitrary file upload vulnerability that was being actively exploited within days of its September 2021 disclosure, appeared in that first batch. So did CVE-2017-11882, a Microsoft Office memory corruption vulnerability from 2017 that remained in active use by threat actors years after its initial disclosure — a reminder that patching debt accumulates and old vulnerabilities stay dangerous indefinitely when unpatched systems persist.

The catalog crossed 500 entries in early 2022, 750 entries by mid-2022, and surpassed 1,000 by early 2023. The rate of additions has reflected the threat landscape: periods of intense exploitation activity — such as the spring 2023 wave of MOVEit SQL injection exploitation (CVE-2023-34362), the Barracuda Email Security Gateway backdoor (CVE-2023-2868), and the Cisco IOS XE web UI privilege escalation (CVE-2023-20198) — produce clusters of KEV additions within days of public disclosure. In some cases, CISA has added entries within 24 to 48 hours of a vendor advisory when exploitation evidence was already in hand.

Top vendors by KEV count

Microsoft consistently leads the catalog by entry count, a reflection of the Windows and Office attack surface that dominates enterprise environments worldwide. The Microsoft entries span Windows kernel elevation-of-privilege vulnerabilities, Internet Explorer and Edge browser memory corruption bugs, Exchange Server remote code execution flaws, and SharePoint deserialization vulnerabilities — a cross-section of every major attack surface the company supports.

Apple, Cisco, Adobe, and Google round out the top five by count, but the catalog contains entries from hundreds of vendors. What makes the KEV distribution analytically interesting is not the top of the list but the long tail. Legacy and industrial vendors appear with regularity: Advantech, Siemens, Schneider Electric, and Rockwell Automation entries reflect the growing exploitation of operational technology and industrial control systems. SCADA and ICS vulnerabilities that would have seemed niche security concerns a decade ago now appear alongside Windows kernel bugs in the same mandatory federal patch list, documenting the convergence of enterprise IT and industrial network threat landscapes.

Smaller software vendors whose products occupy critical positions in enterprise infrastructure also appear with frequency disproportionate to their market share. Zoho ManageEngine, Palo Alto Networks, Fortinet, and Ivanti collectively account for a meaningful share of entries from 2022 onward, reflecting threat actor focus on network edge devices, VPN appliances, and IT management platforms that sit at high-value positions in target networks and often run without the patch cadence applied to endpoint operating systems.

KEV versus CVSS: two different questions

The Common Vulnerability Scoring System scores the theoretical severity of a vulnerability based on its intrinsic properties: the attack vector (network, adjacent, local, physical), whether user interaction is required, what privileges an attacker needs before exploiting it, the confidentiality and integrity impact, and the scope of the impact. CVSS v3.1 produces a base score between 0.0 and 10.0. A score above 9.0 is Critical; 7.0–8.9 is High; 4.0–6.9 is Medium; below 4.0 is Low.

The CVSS base score answers the question: “How bad could this be if exploited against a vulnerable target?” It does not answer: “Is this being actively exploited right now?” These are different questions, and the distinction matters enormously for patch prioritization.

A vulnerability with a CVSS base score of 6.5 — technically Medium severity — that is being actively used in ransomware campaigns targeting critical infrastructure poses an immediate operational risk that a CVSS 9.8 Critical vulnerability with zero known exploitation does not. When security teams triage thousands of open CVEs by CVSS score alone, they may deprioritize the 6.5 behind every Critical and High on their list, some of which may never be exploited in the wild at all. The KEV inverts this logic: it identifies vulnerabilities where the exploitation question has already been answered definitively, regardless of where the theoretical score falls.

Joining the KEV catalog to NVD CVSS data reveals that a non-trivial fraction of KEV entries carry CVSS base scores below 7.0. These are the entries most likely to be deprioritized by a CVSS-only patch workflow and most likely to represent the gap between theoretical severity models and real-world attacker behavior. The Python snippet below surfaces this distribution.

EPSS: a complementary predictive signal

The Exploit Prediction Scoring System, maintained by the Forum of Incident Response and Security Teams (FIRST), takes a different approach from both CVSS and KEV. EPSS is a machine learning model that assigns each CVE a probability score (0.0 to 1.0) representing the likelihood that the vulnerability will be exploited in the wild within the next 30 days. The model is trained on data about past exploitation patterns and updated daily. An EPSS score of 0.80 means the model estimates an 80% probability that the vulnerability will be observed in active exploitation within a month.

EPSS and KEV serve complementary roles. KEV is retrospective and definitive: it lists vulnerabilities where exploitation has already been confirmed. EPSS is predictive and probabilistic: it estimates which vulnerabilities are likely to become exploited. Using both together enables a two-tier prioritization strategy. The KEV provides the mandatory floor — patch these first, period. EPSS provides the forward-looking tier: among the thousands of open CVEs not yet on the KEV, prioritize those with high EPSS scores because they are statistically most likely to join the KEV soon. A security team working this way focuses finite patch resources on the intersection of confirmed exploitation and predicted-near-exploitation rather than on theoretical maximum severity.

EPSS scores are available via the FIRST API at https://api.first.org/data/1.0/epss. The API accepts CVE IDs as query parameters and returns the current score and percentile for each CVE requested. FIRST also publishes bulk CSV downloads of all current EPSS scores, updated daily, at https://epss.cyentia.com/epss_scores-YYYY-MM-DD.csv.gz.

Python: downloading KEV and joining to NVD CVSS data

The script below downloads the KEV JSON feed, loads CVSS scores from the NVD REST API, joins them on CVE ID, writes a combined CSV, and prints a breakdown of KEV entries by CVSS severity band. No third-party dependencies are required beyond the standard library for the core download; the NVD rate limit applies without a registered API key (5 requests per 30 seconds).

import json
import urllib.request
import csv
import io

# ── 1. Download the KEV catalog (JSON) ──────────────────────────────────────
KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"

with urllib.request.urlopen(KEV_URL) as response:
    kev_data = json.loads(response.read().decode())

vulnerabilities = kev_data["vulnerabilities"]
print(f"KEV catalog version: {kev_data['catalogVersion']}")
print(f"Total entries: {len(vulnerabilities)}")
# Example fields in each entry:
#   cveID, vendorProject, product, vulnerabilityName,
#   dateAdded, shortDescription, requiredAction, dueDate, notes

# ── 2. Build a lookup dict keyed by CVE ID ──────────────────────────────────
kev_by_cve = {v["cveID"]: v for v in vulnerabilities}

# ── 3. Download NVD CVE data (JSON feed) for CVSS scores ───────────────────
# NVD publishes annual feeds; use the 2023 feed for demonstration.
# Full list at https://nvd.nist.gov/vuln/data-feeds (legacy) or the
# NVD REST API at https://services.nvd.nist.gov/rest/json/cves/2.0
#
# Here we use the REST API with a page loop (2,000 results per page).
import time

NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"
nvd_scores = {}          # cveId -> {"cvssV3BaseScore": float, "severity": str}
start_index = 0
results_per_page = 2000

while True:
    url = f"{NVD_API}?startIndex={start_index}&resultsPerPage={results_per_page}"
    with urllib.request.urlopen(url) as r:
        page = json.loads(r.read().decode())

    for item in page.get("vulnerabilities", []):
        cve_id = item["cve"]["id"]
        metrics = item["cve"].get("metrics", {})
        v31 = metrics.get("cvssMetricV31", [])
        v30 = metrics.get("cvssMetricV30", [])
        v2  = metrics.get("cvssMetricV2",  [])
        if v31:
            score = v31[0]["cvssData"]["baseScore"]
            sev   = v31[0]["cvssData"]["baseSeverity"]
        elif v30:
            score = v30[0]["cvssData"]["baseScore"]
            sev   = v30[0]["cvssData"]["baseSeverity"]
        elif v2:
            score = v2[0]["cvssData"]["baseScore"]
            sev   = "n/a (CVSSv2)"
        else:
            score, sev = None, None
        nvd_scores[cve_id] = {"cvssBaseScore": score, "severity": sev}

    total = page.get("totalResults", 0)
    start_index += results_per_page
    if start_index >= total:
        break
    time.sleep(6)   # NVD rate limit: 5 requests per 30 seconds without API key

print(f"NVD CVEs loaded: {len(nvd_scores):,}")

# ── 4. Join KEV entries to NVD CVSS scores ───────────────────────────────────
rows = []
for cve_id, entry in kev_by_cve.items():
    nvd = nvd_scores.get(cve_id, {})
    rows.append({
        "cveID":             cve_id,
        "vendorProject":     entry["vendorProject"],
        "product":           entry["product"],
        "vulnerabilityName": entry["vulnerabilityName"],
        "dateAdded":         entry["dateAdded"],
        "dueDate":           entry.get("dueDate", ""),
        "cvssBaseScore":     nvd.get("cvssBaseScore"),
        "severity":          nvd.get("severity"),
        "requiredAction":    entry["requiredAction"],
    })

# ── 5. Write joined CSV ───────────────────────────────────────────────────────
out_buf = io.StringIO()
fieldnames = ["cveID","vendorProject","product","vulnerabilityName",
              "dateAdded","dueDate","cvssBaseScore","severity","requiredAction"]
writer = csv.DictWriter(out_buf, fieldnames=fieldnames)
writer.writeheader()
writer.writerows(rows)

with open("kev_with_cvss.csv", "w") as f:
    f.write(out_buf.getvalue())

# ── 6. Summary: KEV entries by CVSS severity band ────────────────────────────
from collections import Counter
severity_counts = Counter(
    r["severity"] for r in rows if r["severity"]
)
for band, count in sorted(severity_counts.items(), key=lambda x: -x[1]):
    print(f"  {band:12s}: {count:4d} entries")

# Key finding: a meaningful share of KEV entries score below CVSS 7.0 (HIGH).
# These lower-scored vulnerabilities are on the list because they are
# actively exploited -- not because they are theoretically dangerous.

The severity band breakdown typically shows that the majority of KEV entries are CVSS High or Critical — exploitation tends to concentrate in high-impact vulnerabilities — but the Medium and lower entries are the analytically interesting ones. They are the cases where attacker behavior has diverged most sharply from what the CVSS model predicted. These are the vulnerabilities most likely to be deprioritized by an organization running a CVSS-only patch program, and therefore the vulnerabilities most likely to represent systematic gaps in patching workflows at scale.

How security teams use KEV in practice

A mature enterprise runs continuous vulnerability scanning across its environment. The output of that scanning — from tools like Tenable Nessus, Qualys, Rapid7 InsightVM, or Microsoft Defender Vulnerability Management — is typically tens of thousands of open findings at any given time. CVSS scoring is insufficient to reduce this to a manageable action list. Every organization has more High and Critical findings than it can remediate on any given patch cycle.

KEV provides a principled way to establish a mandatory minimum. Any CVE on the KEV catalog that appears in vulnerability scan results gets patched first, on the federal deadline schedule if the organization chooses to align to BOD 22-01, or on its own equivalent deadline. This set is typically small relative to the total open finding count — KEV entries in any given scanner output might represent a few dozen CVEs rather than thousands — and every one of them has confirmed real-world exploitation evidence rather than just a theoretical severity score.

The KEV-first model creates a two-queue patch workflow. Queue one is KEV findings: these are worked immediately, on a deadline, by the most available engineering resources. Queue two is everything else: these are triaged using CVSS, EPSS, asset criticality, and compensating control context. Queue two items may be deprioritized, accepted, or remediated over a longer horizon based on business risk tolerance. Queue one has no such flexibility; the evidence of active exploitation removes the uncertainty that would otherwise justify delay.

Many commercial vulnerability management platforms now integrate KEV status directly into their finding views. A finding flagged as KEV-listed surfaces at the top of dashboards regardless of its CVSS score. Some platforms also expose EPSS scores alongside KEV status, enabling the combined prioritization strategy described above. For organizations that have not adopted such integrations, automating the daily diff of the KEV JSON feed against internal scanner outputs is a straightforward engineering task: download the JSON, extract CVE IDs, intersect with open scanner findings, and page the relevant team.

BOD 22-01 and the federal mandate

Binding Operational Directive 22-01, issued by CISA on November 3, 2021 (the same day as the initial KEV publication), is titled “Reducing the Significant Risk of Known Exploited Vulnerabilities.” It applies to all federal civilian executive branch agencies — commonly abbreviated as FCEB — and requires them to remediate KEV vulnerabilities by the due dates listed in the catalog.

The directive established a remediation timeline structure: vulnerabilities in the initial catalog had either a six-month or a two-week deadline depending on when they were assessed. For vulnerabilities added after the initial release, CISA sets the due date individually at the time of listing, typically two weeks for vulnerabilities posing immediate risk and up to six months for others. When an agency cannot remediate by the due date, BOD 22-01 requires it to submit a plan of action and milestones documenting why remediation is delayed and the projected completion date.

BOD 22-01 is legally binding only on FCEB agencies. It does not apply to state and local governments, critical infrastructure operators, or the private sector. However, CISA explicitly encourages all organizations to use the KEV catalog as a prioritization resource, and many regulated industries — finance, healthcare, energy — have incorporated KEV status into their voluntary or contractually required vulnerability management programs. The catalog's public availability at no cost and in machine-readable formats makes adoption operationally straightforward regardless of regulatory status.

Cross-reference: KEV and the broader vulnerability ecosystem

The KEV catalog is most powerful when treated as one layer in a multi-source vulnerability intelligence stack. Each CVE in the catalog links directly to the corresponding NVD entry, which contains the full CVSS vector string, affected product CPE data, CWE classification, and references to vendor advisories and public exploit repositories. Joining KEV entries to NVD allows analysts to understand the vulnerability class distribution across the catalog: which CWEs — improper input validation, use-after-free, improper authentication — appear most often in actively exploited vulnerabilities, and whether that distribution differs from the broader CVE population.

The Exploit Database at exploit-db.com and the Metasploit module list at github.com/rapid7/metasploit-framework provide exploit availability data that complements KEV. When a CVE is KEV-listed and also has a public Metasploit module, the exploit is accessible to a much broader range of attackers than when exploitation requires custom tooling. This combination — confirmed exploitation evidence plus commoditized exploit tooling — represents the highest-urgency tier for patch prioritization.

For healthcare-specific analysis, cross-referencing KEV entries against the HHS-OCR HIPAA breach database by date provides a retrospective view of how quickly confirmed exploitation events translate into breach disclosures in the sector. MOVEit (CVE-2023-34362) was added to the KEV on May 31, 2023; healthcare breach reports referencing MOVEit-involved vendor compromises began appearing in the HHS-OCR data within weeks, illustrating the speed at which a KEV-listed vulnerability moves from federal alert to reported breach at regulated entities.