CISA Known Exploited Vulnerabilities: The Federal List of What Attackers Are Actually Using

There are hundreds of thousands of catalogued software vulnerabilities, and no organization on earth can patch them all at once. The federal government's answer to that impossible arithmetic is a short list: the Known Exploited Vulnerabilities catalog, a curated register of the flaws that attackers are demonstrably using right now. Roughly 1,600 entries, each a single CVE confirmed to be exploited in the wild, each carrying the vendor, the product, what to do about it, and a hard deadline to do it by. It is the highest-signal vulnerability feed the United States publishes—the difference between a theoretical risk and a fire already burning.

This article covers what the KEV catalog is and why a federal cybersecurity agency maintains it; the idea of risk-based vulnerability management that KEV embodies, and why a severity score alone is not enough; the legal teeth—Binding Operational Directive 22-01—that turn the list into an enforceable patching mandate across the federal civilian government; the fields each entry carries, including the ransomware-campaign flag; how the catalog joins to the NIST National Vulnerability Database for CVSS severity, CWE weakness type, and affected products; its role as one of the lists in security and compliance screening; a worked Python example that pulls the catalog and tallies additions by year and by vendor while isolating the ransomware-associated entries; and the caveats—an evidence-gated list is a floor, not a ceiling—that every analyst must keep in mind.

What it is

The Known Exploited Vulnerabilities (KEV) catalog is maintained by the Cybersecurity and Infrastructure Security Agency (CISA), the operational cybersecurity arm of the Department of Homeland Security. CISA stood up the catalog in late 2021, and its purpose is narrow and powerful: it is the authoritative federal list of software vulnerabilities that have been confirmed to be actively exploited in the wild. That qualifier is the whole point. The world's vulnerabilities are tracked through the Common Vulnerabilities and Exposures (CVE) system, which has catalogued hundreds of thousands of distinct flaws. The overwhelming majority of those CVEs are never exploited at scale—they describe weaknesses that exist in principle but that no attacker has been observed using. The KEV catalog is the curated, high-signal subset: the CVEs for which CISA has reliable evidence of real-world exploitation.

In our database the catalog is stored as the table cisa_kev, with the grain of one row per exploited CVE—roughly 1,600 entries, keyed by the CVE identifier. The list grows over time as CISA confirms exploitation of additional vulnerabilities; entries are added, with a date, when the evidence arrives, and the catalog is published as a single JSON file and a parallel CSV that anyone can download without a key. Each row is engineered to answer the only questions a defender under time pressure actually has—which flaw, in whose software, how bad, and by when must it be fixed:

cve_id                          -- the CVE identifier (e.g. CVE-2021-44228), primary key
vendor_project                  -- the maintaining vendor or open-source project
product                         -- the affected product
vulnerability_name              -- short human-readable name for the flaw
date_added                      -- date CISA added it (i.e. confirmed exploitation)
short_description               -- one-paragraph summary of the vulnerability
required_action                 -- what remediators must do (patch, mitigate, or discontinue)
due_date                        -- remediation deadline assigned by CISA
known_ransomware_campaign_use   -- "Known" if tied to ransomware campaigns, else "Unknown"
notes                           -- references and links to advisories / patches

The cve_id is the load-bearing column. The CVE identifier is the universal, persistent name for a specific vulnerability—a year and a sequence number—assigned through the CVE program and used by virtually every security tool, vendor advisory, and vulnerability database in existence. Because KEV keys on the CVE ID, every entry is instantly joinable to the much richer record the rest of the security ecosystem keeps about that same flaw. The date_added is more useful than it first appears: it marks not when the vulnerability was discovered or published, but when CISA confirmed it was being exploited, which makes it the right axis for measuring the cadence of real attacks rather than the cadence of disclosure. The due_date and required_action are what distinguish KEV from a passive feed: they are instructions, not observations. And the known_ransomware_campaign_use flag, added to the schema as ransomware became the dominant threat to critical infrastructure, singles out the entries tied to the campaigns that have shut down hospitals, pipelines, and municipal governments.

Why KEV exists: risk-based vulnerability management

To understand why a federal agency curates this list at all, you have to understand the problem it solves. Every large organization runs vulnerability scanners that, on any given week, return thousands or tens of thousands of findings—every unpatched flaw in every piece of software across the estate. No security team can remediate all of them simultaneously; patching is disruptive, requires testing, and competes with every other demand on operations. So the central question of vulnerability management is not can we fix everything but what do we fix first. KEV is the federal government's answer to that prioritization problem.

For years the default answer was to prioritize by severity score—chiefly the Common Vulnerability Scoring System (CVSS), which rates each flaw from 0 to 10 on how damaging it would be if exploited. CVSS is genuinely useful, but as a sole prioritization tool it has a fatal flaw: it measures potential impact, not likelihood of attack. A vulnerability can carry a maximum CVSS score and never be exploited because it is hard to reach, requires unusual preconditions, or simply has not attracted attacker interest—while a more modest-scoring flaw in ubiquitous software gets weaponized within days. Treating every high-CVSS vulnerability as equally urgent floods a team with theoretically-severe findings and buries the handful that attackers are actually using. The result is teams that patch furiously and still get breached, because they were optimizing the wrong variable.

Risk-based vulnerability management reframes the question around real-world risk: combine how bad a flaw is with how likely it is to be exploited, and remediate where the product of the two is highest. KEV supplies the most decisive input to that calculation—not a probability estimate but a binary fact. A vulnerability on the KEV catalog is not likely to be exploited; it is being exploited. That single bit collapses an enormous amount of uncertainty. It is why the practical guidance built around KEV is blunt: whatever else your program does, remediate the KEV vulnerabilities present in your environment first, because those are the ones the data says someone is using to break in. The catalog pairs naturally with forward-looking signals like the Exploit Prediction Scoring System (EPSS), which estimates the probability that a given CVE will be exploited—KEV tells you what already is, EPSS tells you what is coming—and with decision frameworks such as SSVC that weigh exploitation status alongside exposure and mission impact.

BOD 22-01 and the federal patching mandate

What turns KEV from a useful advisory list into something with real force is a piece of federal directive authority: Binding Operational Directive 22-01, issued by CISA in November 2021 and titled, plainly, “Reducing the Significant Risk of Known Exploited Vulnerabilities.” A binding operational directive is a compulsory instruction that CISA, under its statutory authority, can issue to federal civilian executive-branch agencies—the departments and agencies of the executive branch outside the national-security and defense systems that fall under other authorities. BOD 22-01 directs those agencies to remediate the vulnerabilities in the KEV catalog.

The mechanism is what makes it work. Rather than mandate patching of some sprawling, unmanageable universe of vulnerabilities, the directive ties the obligation to the catalog: agencies must remediate each KEV entry that is present in their environment by the due date CISA assigns to that entry. The due date is the enforcement clock—it is why every KEV row carries a due_date field. CISA sets shorter remediation windows for the most urgent, recently-added flaws and longer ones for older entries, and the agencies report their progress. In one stroke the directive converts a curated intelligence product into an auditable, government-wide patching schedule: the list is the scope, the due dates are the timeline, and the directive is the obligation.

The effect has reached well beyond the federal agencies the directive legally binds. Because KEV is public, evidence-based, and explicitly designed for prioritization, it has become a de facto standard in the private sector. Vendors of vulnerability-management and endpoint tools tag findings with KEV status; cyber insurers and auditors ask whether KEV vulnerabilities are remediated; contracts and frameworks increasingly reference the catalog. A list created to discipline federal patching has become the common reference point for “the vulnerabilities everyone agrees you must fix,” which is precisely the network effect CISA hoped a single authoritative, no-cost, exploitation-gated list could produce. The directive gave KEV teeth inside government; its quality and openness gave it adoption outside.

The fields, and the ransomware flag

The KEV schema is deliberately spare, and each field earns its place. The vendor_project and product fields name where the flaw lives, which is how a defender maps an entry to their own asset inventory—a KEV entry only matters to you if you run the affected product. The vulnerability_name and short_description give a human-readable handle and a one-paragraph summary, so an analyst can grasp the nature of the flaw without leaving the catalog. The required_action field is the instruction—usually “apply the vendor's patch,” but sometimes a mitigation where no patch exists, or, in the most serious cases, “discontinue use of the product” when a vendor has gone out of support and the flaw cannot be fixed at all. That last action is rare and consequential: it is the federal government telling agencies to rip a product out entirely.

The most analytically interesting field is known_ransomware_campaign_use. CISA added it to the catalog because ransomware became the defining threat to hospitals, schools, utilities, and local governments, and because defenders asked for a way to triage within KEV itself—to find, among the exploited vulnerabilities, the ones that the ransomware crews are actually leveraging to gain their initial foothold or to move laterally. The field carries “Known” when CISA has evidence the vulnerability has been used in ransomware campaigns and “Unknown” otherwise (where “unknown” means no confirmed ransomware association, not that the flaw is unimportant). For an under-resourced organization—the rural hospital, the county IT department—the ransomware-flagged subset of KEV is the shortest, sharpest priority list there is: these are the exploited vulnerabilities tied to the attacks most likely to take the organization offline and demand a ransom. Filtering KEV down to the ransomware-flagged entries, and then to the products you actually run, produces a remediation list a small team can plausibly act on this week.

Joining to the NIST NVD: CVSS, CWE, and affected products

KEV is intentionally minimal—it tells you that a vulnerability is exploited and what to do, but it deliberately does not duplicate the deep technical metadata that other systems already maintain. That metadata lives in the National Vulnerability Database (NVD), the U.S. government repository of CVE detail run by the National Institute of Standards and Technology. Because both KEV and the NVD key on the CVE ID, joining them is trivial and enormously enriching: KEV supplies the exploitation signal and the deadline, the NVD supplies everything else known about the flaw.

Three NVD attributes are the most valuable additions. The first is the CVSS score and vector—the severity rating and its component metrics (attack vector, attack complexity, privileges required, the impact on confidentiality, integrity, and availability). Joining CVSS onto KEV lets an analyst do something neither dataset supports alone: distinguish the exploited-and-severe vulnerabilities from the exploited-but-modest ones, and observe the frequently-uncomfortable fact that some heavily-exploited flaws carry only middling CVSS scores—direct evidence that severity and exploitation are different axes. The second is the CWE (Common Weakness Enumeration) classification, which categorizes the underlying weakness type—memory corruption, injection, authentication bypass, deserialization, path traversal. Aggregating KEV by CWE reveals which classes of bug attackers favor in practice, a far more actionable insight for secure-development priorities than any single CVE. The third is the structured list of affected products and versions (the CPE applicability data), which lets a defender mechanically match KEV entries against a software inventory rather than reading product names by eye.

In our database cisa_kev is designed to be joined to the NVD CVE table on the CVE ID precisely so that the exploitation flag and the remediation deadline travel together with CVSS severity, CWE weakness type, and affected-product data. The combination is more than the sum of its parts: KEV without the NVD is a list of names and deadlines; the NVD without KEV is a vast catalog with no prioritization. Together they let an analyst rank a real environment's exposures by the right composite—is it exploited, how severe, what weakness class, and do we run it—which is exactly what risk-based vulnerability management asks for.

KEV in compliance and security screening

Beyond its operational use inside security teams, KEV functions as one of the reference lists in compliance and security screening—the same broad discipline of checking a subject against authoritative federal lists that drives sanctions, debarment, and enforcement screening, applied here to software risk rather than to counterparties. The catalog appears in screening pipelines in several distinct ways.

In third-party and vendor risk, an organization assessing a supplier's security posture can check whether the products that supplier runs—or sells—carry open KEV vulnerabilities, treating an unremediated KEV flaw as a material red flag in a due-diligence questionnaire or a continuous-monitoring feed. In procurement and contract compliance, references to BOD 22-01 and the KEV catalog increasingly appear in the security clauses that bind federal contractors, so that “remediate KEV entries by their due dates” becomes a contractual obligation that flows down the supply chain. And in attack-surface and software-bill-of-materials (SBOM) screening, automated tools cross-reference the components in a software inventory against the KEV catalog to surface, immediately, any shipped or deployed component with a known-exploited flaw—the software analogue of running a vendor name against an exclusion list. In each case KEV plays the role a good screening list always plays: a short, authoritative, machine-readable register against which a subject can be checked, with a hit carrying a clear, defensible meaning.

Analytical uses

Treated as a dataset rather than a checklist, the KEV catalog supports a range of analysis into the shape of real-world exploitation that no severity database alone can deliver.

Exploitation cadence over time is the most immediate. Because every entry carries a date_added that marks confirmed exploitation, tallying additions by month or year produces a timeline of how quickly the catalog grows and when surges occur—the spikes that follow the disclosure of a widely-deployed, easily-weaponized flaw. Reading the cadence alongside the dates the underlying CVEs were published also yields the exploitation lag: how long, on average, between a vulnerability becoming public and CISA confirming it is being used—a number that has compressed sharply as attackers have grown faster at operationalizing new flaws.

Vendor and product concentration exploits the vendor_project and product fields. Counting KEV entries by vendor shows which platforms attackers return to most often—invariably dominated by the ubiquitous operating systems, browsers, network appliances, and enterprise applications, because attackers target what is everywhere. This is not a verdict on any vendor's security relative to its peers—ubiquity and scrutiny inflate the count—but it is a clear-eyed map of where an organization's exposure concentrates. Layering the ransomware flag on top isolates the vendors and products most entangled with ransomware operations, the sharpest possible triage for the organizations ransomware hits hardest. And joining to the NVD's CWE classification turns the catalog into a study of which weakness classes get exploited in practice—the empirical complement to secure-coding guidance, grounding “what to defend against” in what attackers have actually used.

Python workflow: pulling the catalog and tallying by year, vendor, and ransomware

CISA publishes the entire KEV catalog as a single JSON file (with a parallel CSV) at a stable URL, with no API key and no meaningful rate limit—it is one flat download of every entry. The script below fetches the JSON, reads the catalog version and count from the wrapper, and then produces three of the core views: additions by year (the exploitation cadence), the most-represented vendors, and the ransomware-flagged subset with its own vendor breakdown. It closes with an illustrative check of how many entries are already past their remediation due date. Requirements: requests and pandas.

import requests
import pandas as pd
from collections import Counter

# CISA Known Exploited Vulnerabilities (KEV) catalog.
#
# CISA publishes the full catalog as a single JSON file (and a parallel
# CSV) at a stable URL. No API key is required and there is no rate limit
# of consequence -- it is one flat download of every KEV entry.
#   JSON: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
#   CSV:  https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv
KEV_JSON = ("https://www.cisa.gov/sites/default/files/feeds/"
            "known_exploited_vulnerabilities.json")


def load_kev(url=KEV_JSON):
    r = requests.get(url, timeout=120)
    r.raise_for_status()
    doc = r.json()
    # The document wraps a catalog version, a release date, a running
    # count, and the list of vulnerabilities under "vulnerabilities".
    print(f"Catalog version: {doc.get('catalogVersion')}  "
          f"released {doc.get('dateReleased')}  "
          f"count {doc.get('count'):,}")
    return pd.DataFrame(doc["vulnerabilities"])


kev = load_kev()
print(f"KEV entries loaded: {len(kev):,}")

# Field names follow the published schema: cveID, vendorProject, product,
# vulnerabilityName, dateAdded, dueDate, requiredAction, knownRansomware-
# CampaignUse, and a short shortDescription.

# --- 1. Additions by year -----------------------------------------------
# dateAdded is when CISA confirmed in-the-wild exploitation and added the
# CVE -- a better cadence signal than the CVE's own publication year.
kev["dateAdded"] = pd.to_datetime(kev["dateAdded"], errors="coerce")
by_year = kev["dateAdded"].dt.year.value_counts().sort_index()
print("\nKEV additions by year:")
for yr, n in by_year.items():
    print(f"  {int(yr)}  {n:>5,}")

# --- 2. Top vendors on the list -----------------------------------------
# vendorProject is the maintaining vendor/project. A handful of large
# platform vendors dominate simply because their software is everywhere.
print("\nTop 15 vendors by KEV entries:")
for vendor, n in kev["vendorProject"].value_counts().head(15).items():
    print(f"  {vendor[:38]:<38} {n:>4,}")

# --- 3. Ransomware-associated entries -----------------------------------
# Many entries are flagged for known use in ransomware campaigns. The
# field is a yes/no-style string; normalize before counting.
flag = (kev["knownRansomwareCampaignUse"].fillna("")
        .str.strip().str.lower())
ransomware = kev[flag.eq("known")]
share = len(ransomware) / max(len(kev), 1)
print(f"\nEntries flagged for known ransomware-campaign use: "
      f"{len(ransomware):,} ({share:.1%} of the catalog)")

# Which vendors show up most often in the ransomware-flagged subset?
print("Top vendors among ransomware-flagged KEV entries:")
for vendor, n in ransomware["vendorProject"].value_counts().head(8).items():
    print(f"  {vendor[:38]:<38} {n:>4,}")

# --- Overdue check (illustrative) ---------------------------------------
# Federal civilian agencies must remediate each entry by its dueDate.
# A simple "what is already past due as of today" view:
kev["dueDate"] = pd.to_datetime(kev["dueDate"], errors="coerce")
past_due = kev[kev["dueDate"] < pd.Timestamp.now()]
print(f"\nEntries whose remediation due date has passed: {len(past_due):,}")

Two notes on using the script in earnest. First, the date_added axis is the right one for measuring attacker tempo, but it is a property of when CISA confirmed exploitation, not when the flaw was born—to study the exploitation lag you must join in each CVE's publication date from the NVD and difference the two, which is the natural next step once the catalog is in hand. Second, the past-due check at the end is purely illustrative against the catalog's assigned due dates; it is not a measure of any particular organization's compliance, because whether a KEV entry is overdue for you depends entirely on whether you run the affected product—which requires matching the catalog against a real asset inventory, the join that turns this national list into a local remediation plan.

Limitations and analytical caveats

The KEV catalog is the highest-signal vulnerability list the federal government publishes, but its very design—an evidence-gated, deliberately small list—creates limitations an analyst must hold firmly in mind.

KEV is a floor, not a ceiling. The catalog lists vulnerabilities for which CISA has confirmed exploitation. A vulnerability not on KEV is not safe—it may be exploited without CISA having yet seen or confirmed the evidence, or exploited in ways that never surface publicly. Treating “not on KEV” as “not a threat” is the inverse of the mistake KEV exists to fix: the list is a high-confidence prioritization aid, the set of vulnerabilities you must certainly address, not an exhaustive map of everything dangerous. A mature program uses KEV to set the floor of urgency and continues to manage the broader universe of risk above it.

There is an inclusion lag, and the list is curated.An entry appears only after CISA gathers and validates evidence of exploitation, so there is a gap—sometimes days, sometimes longer—between a vulnerability first being exploited and its appearance on the catalog. During that window the flaw is being used but is not yet on the list. The curation that makes KEV trustworthy is the same curation that makes it lag: a list that added every rumored exploit instantly would be noisier and less authoritative, but the price of high confidence is that the catalog trails the leading edge of attacker activity. KEV is authoritative for confirmed exploitation; it is not a real-time zero-day feed.

Vendor counts reflect ubiquity, not relative insecurity. Because attackers target the software that is everywhere, the vendors and products atop any KEV tally are the platforms with the largest installed base and the most security scrutiny. A high KEV count is a function of prevalence and attacker attention, not a clean measure of a vendor's engineering quality relative to a less-targeted peer. Any analysis that ranks vendors by KEV entries and reads the ranking as a security scorecard is mostly measuring market share. The honest reading is exposure-mapping— where the world's exploited risk concentrates—not a league table of vendor blame.

An entry only matters if you run the product, and the data is a summary. A KEV row is a national statement about a vulnerability; its relevance to any organization is entirely contingent on whether that organization runs the affected product and version. The catalog cannot tell you that—it must be matched against an asset inventory, and the quality of that match (down to specific versions and configurations) determines whether the list yields a real remediation plan or a pile of irrelevant entries. And like any structured feed, KEV compresses each flaw into a few fields; the full technical detail, the proof-of-exploitation, and the patch specifics live in the linked advisories and in the NVD, not in the catalog row itself. Read with these limits respected, cisa_kev is what it was built to be: the short, authoritative, deadline-bearing list of the software flaws attackers are actually using—the place a defender starts, joined to the NVD for depth and to an asset inventory for relevance, on the way to fixing the things that are on fire before worrying about the things that merely could be.