Skip to main content
Change Risk Intel
Cybersecurity

How to Read a CISA KEV Entry and What to Do Next

Ben Ennis · 16 min read

Why this matters right now

The CISA Known Exploited Vulnerabilities Catalog held more than 1,400 entries as of late September 2025, and CISA adds new ones multiple times a week — sometimes daily during active incident response, as shown in its running feed of KEV catalog additions. Every one of those additions carries a due date that Federal Civilian Executive Branch (FCEB) agencies are legally required to meet, and every one is a signal the rest of the market treats as a de facto “patch this now” order. When CISA added the Fortra GoAnywhere MFT deserialization flaw to KEV on September 29, 2025, agencies had until October 20, 2025 to remediate — three weeks, for a vulnerability Microsoft had already tied to Medusa ransomware intrusions across five industry sectors, according to Microsoft’s threat intelligence writeup. If your CAB doesn’t have a standing process for reading and routing KEV entries, that three-week clock is already running down before anyone in your change pipeline notices.

What is the CISA KEV catalog?

The KEV catalog is CISA’s phrase for it: “the authoritative source of vulnerabilities that have been exploited in the wild,” maintained “for the benefit of the cybersecurity community and network defenders” and intended as “an input to a vulnerability management prioritization framework” — not a replacement for one, according to CISA’s own catalog page. It is not a list of dangerous-looking CVEs, and it is not a severity ranking. It is a curated list of CVEs that CISA has confirmed are being actively exploited, gated by three criteria CISA has published: the vulnerability must have an assigned CVE ID, there must be reliable evidence of active in-the-wild exploitation, and there must be a clear remediation action available, per CISA’s inclusion criteria.

The catalog exists because of Binding Operational Directive 22-01, issued November 3, 2021. BOD 22-01 established the KEV catalog specifically “to reduce the significant risk of known exploited vulnerabilities” and created binding remediation requirements for federal agencies tied to it. It replaced ad-hoc scanning-based prioritization with a single, continuously updated exploitation list that agencies — and, by extension, most of the private sector — now treat as the floor for “you should already have patched this.”

What are the ten fields in a KEV entry?

Every entry in the KEV JSON feed and the public catalog schema on GitHub follows the same structure. Below is a real entry — CVE-2025-10035, the Fortra GoAnywhere MFT flaw — with each field explained.

FieldValue in this entryWhat it tells you
cveIDCVE-2025-10035The unique CVE identifier. Use it to cross-reference NVD, your scanner, and your asset inventory.
vendorProjectFortraThe vendor responsible for the affected product.
productGoAnywhere MFTThe specific product line affected — check this against your CMDB, not just the vendor name.
vulnerabilityNameFortra GoAnywhere MFT Deserialization of Untrusted Data VulnerabilityA human-readable name, useful for CAB agendas and ticket titles.
dateAdded2025-09-29The date CISA added it to KEV — not the disclosure date. Use this to measure your organization’s mean-time-to-remediate against the KEV clock.
shortDescription”Fortra GoAnywhere MFT contains a deserialization of untrusted data vulnerability [that] allows an actor with a validly forged license response signature to deserialize an arbitrary actor-controlled object, possibly leading to command injection.”A plain-language summary of the flaw mechanism — enough to brief a CAB without reading the full advisory.
requiredAction”Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.”The concrete step. Almost always points back to the vendor advisory.
dueDate2025-10-20The FCEB remediation deadline — 21 days after dateAdded for a post-2021 CVE, consistent with the two-week-to-six-month window BOD 22-01 sets.
knownRansomwareCampaignUseKnownWhether CISA has confirmed ransomware actors have used this flaw. CISA confirmed this designation when it added the entry, noting the defect “has been used in ransomware campaigns,” as CyberScoop reported from CISA’s own alert.
notesLinks to Fortra’s advisory FI-2025-012 and the NVD recordWhere to go for full technical detail and patch instructions.

Two fields carry more decision weight than the rest for private-sector teams: dueDate and knownRansomwareCampaignUse. Everything else is context; those two are what should move your change calendar.

For this specific entry, Microsoft’s Threat Intelligence team confirmed that a financially motivated group it tracks as Storm-1175 — a known Medusa ransomware affiliate — exploited CVE-2025-10035 starting September 11, 2025, using it for initial access before deploying remote monitoring tools, moving laterally with built-in Windows utilities, exfiltrating data with Rclone, and deploying Medusa ransomware in at least one confirmed victim environment, per Microsoft’s investigation. That’s the kind of detail the notes and vendor-advisory links exist to surface — CISA’s entry itself stays terse by design.

What does BOD 22-01 actually require?

BOD 22-01 draws a hard line between two audiences, and mixing them up is the most common misreading of KEV.

For FCEB agencies, the directive is binding law, not guidance. Per the directive text, agencies must review and update internal vulnerability management procedures within 60 days of the directive’s issuance, remediate every cataloged vulnerability by its dueDate, and report remediation status through the CDM Federal Dashboard or CyberScope. Default remediation timelines are six months for vulnerabilities with a pre-2021 CVE ID and two weeks for anything newer — though CISA can shorten this “in the case of grave risk to the Federal Enterprise,” which is why some entries (like the two Cisco ASA/FTD flaws added under Emergency Directive 25-03 in September 2025) carry due dates of a single day.

For everyone else — commercial enterprises, regulated industries, MSPs — BOD 22-01 has no legal force. But that’s not the same as no relevance. Because CISA’s inclusion bar requires confirmed active exploitation, not theoretical risk, KEV membership is one of the few “someone is definitely using this against real targets” signals available anywhere for free. Most vulnerability management programs — and increasingly, cyber insurance underwriters — treat KEV membership as an override that jumps a CVE to the front of the patch queue regardless of what its CVSS score says.

How do you feed a new KEV entry into a CAB pre-read?

A KEV entry shouldn’t arrive at your Change Advisory Board as a raw CISA link. Structure the pre-read the same way every time so reviewers can triage in under two minutes:

  1. Header line: CVE ID, product, dateAdded, dueDate, and knownRansomwareCampaignUse value — in that order, before any prose.
  2. Blast radius: cross-reference vendorProject/product against your CMDB or asset inventory. State the count of affected instances, not just “we use this vendor.”
  3. Exploitation context: one paragraph summarizing what the shortDescription, vendor advisory, and any NVD metrics (CVSS, and EPSS if available) say about exploit mechanism and severity.
  4. Proposed action and window: whether this is a standard, expedited, or emergency change, tied explicitly to dueDate minus your internal testing lead time — see our guide to running a CAB meeting for how to slot emergency items into a standing agenda.
  5. Rollback plan: one line. If there isn’t one, that’s the discussion item, not the patch itself.

This is the same structure our 12 external risk sources every CAB should monitor piece recommends for any external signal entering the change pipeline — KEV is simply the highest-confidence source on that list, because CISA’s inclusion criteria already did the “is this real” work for you.

What changes when knownRansomwareCampaignUse is “Known”?

CISA added this field to the catalog through its Ransomware Vulnerability Warning Pilot, which had already generated notifications for more than 800 vulnerable internet-facing systems before the flag became public. When the value flips to “Known,” treat it as a distinct urgency category, not a footnote:

  • Compress your patch window. Ransomware affiliates run opportunistic scanning at scale — the CVE-2025-10035 timeline shows exploitation observed as early as September 10–11, 2025, roughly a week before Fortra’s public advisory. Assume active scanning is already underway by the time you read the entry.
  • Assume compromise, don’t just assume exposure. If a “Known” entry has been unpatched in your environment for any meaningful window, pair the patch change with a compromise-assessment step — Fortra’s own advisory instructed customers to search logs for a specific stack-trace string as a compromise indicator, which is the kind of detail worth pulling into your incident-response runbook alongside the patch ticket.
  • Loop in your CAB emergency-change path, not the standard one. A “Known” ransomware flag is grounds to bypass your normal weekly or biweekly CAB cadence in favor of an expedited or emergency change record, with after-the-fact CAB review rather than before.
  • Watch for silent flips on existing entries. CISA doesn’t only set this flag at intake — it updates it retroactively as evidence accumulates on vulnerabilities already in the catalog. A CVE your team deprioritized months ago as “Unknown” ransomware use can flip to “Known” without a new catalog announcement, so periodic re-checks of open KEV items matter as much as monitoring new ones.

Roughly one in five catalog entries overall carries a “Known” ransomware designation, per third-party analysis of the full KEV dataset — meaning most KEV entries do not carry this flag, which is exactly why the ones that do deserve to skip the queue.

Common misunderstandings about KEV

“KEV membership means the CVE has a high CVSS score.” Not necessarily. KEV is an exploitation signal, not a severity signal. CISA’s own catalog contains CVEs across the CVSS spectrum — the inclusion bar is confirmed active exploitation plus a clear remediation path, independent of the numeric score. A moderate-severity flaw being actively weaponized belongs in KEV; a critical-severity flaw with no observed exploitation does not.

“Every KEV entry is ransomware-related.” Also false — most are not. The knownRansomwareCampaignUse field exists precisely because it’s a minority case worth flagging separately.

“KEV due dates apply to my company.” They apply, by directive, only to FCEB agencies. Your organization can adopt the same due dates as an internal SLA — many regulated firms do — but there is no legal obligation outside the federal civilian executive branch.

“If a vendor hasn’t confirmed exploitation, it’s not really urgent.” CISA’s bar for adding an entry is independent evidence of active exploitation, which sometimes arrives from third-party researchers before the vendor itself confirms it. Fortra had not confirmed active exploitation of CVE-2025-10035 when watchTowr Labs first reported evidence of it — CISA still added it to KEV based on the broader evidence available, per CyberScoop’s reporting at the time.

What to do about it

  1. Subscribe to CISA’s KEV update channel — either the JSON/CSV feed or CISA’s bulletin alerts — rather than relying on someone manually checking the catalog page. Route new entries into a dedicated Slack/Teams channel or ticketing queue automatically.
  2. Pre-build the CAB pre-read template described above so a new entry can be triaged the same day it’s added, not whenever the next scheduled meeting happens to fall.
  3. Map every entry against your CMDB before the CAB meeting, not during it — blast-radius uncertainty is the single biggest reason emergency changes stall.
  4. Set an internal SLA tied to dueDate minus your lead time — for example, “patch or compensating control in place five business days before the federal due date” — so you’re never patching on the deadline itself.
  5. Treat a “Known” ransomware flag as an automatic escalation trigger to your incident-response and emergency-change processes, bypassing the standard CAB cadence.
  6. Re-scan open, unpatched KEV items periodically for ransomware-flag flips, not just new catalog additions.
  7. Cross-reference against your existing patch cycle, including Patch Tuesday releases — a KEV entry for a vulnerability already covered by an upcoming vendor patch cycle may just need acceleration, not a separate emergency change.
  8. Log every KEV-driven change with its CVE ID and dateAdded/dueDate pair in your change record, so post-incident and audit reviews can show time-to-remediate against the federal benchmark even if you’re not an FCEB agency.

Frequently asked questions

What does CISA KEV stand for?

KEV stands for Known Exploited Vulnerabilities. It refers to the CISA-maintained catalog of CVEs that CISA has confirmed are being actively exploited in the wild.

Is CISA KEV the same as a CVSS score?

No. CVSS measures theoretical severity based on exploitability and impact characteristics. KEV membership measures confirmed real-world exploitation. A CVE can have a low CVSS score and still be in KEV if it’s being actively exploited, and a critical CVSS score alone does not guarantee KEV inclusion.

Do private companies have to comply with KEV due dates?

No. BOD 22-01 is binding only on federal civilian executive branch agencies. Private organizations, state and local governments, and critical infrastructure operators outside FCEB have no legal obligation, though CISA “strongly encourages all organizations” to follow the same remediation guidance.

What does it mean when knownRansomwareCampaignUse says “Unknown”?

It means CISA lacks confirmation that ransomware actors have used that specific vulnerability, per the KEV schema definition. It does not mean ransomware use has been ruled out — the value can change to “Known” later without a new catalog announcement.

How often does CISA update the KEV catalog?

There is no fixed schedule. CISA adds entries whenever exploitation evidence meets its inclusion criteria, which can mean multiple additions in a single week or, during major incident response, updates on consecutive days.

Where can I find the raw KEV data for automation?

CISA publishes the catalog as JSON and CSV feeds, plus a documented JSON schema, all linked from the main catalog page. Our CISA KEV Live tool mirrors this feed with change-log highlighting for exactly this kind of monitoring.

Should a KEV entry always trigger an emergency change?

Not always — map it against your existing patch cycle first using a change risk score. A KEV entry for a system already scheduled for patching in the next standard maintenance window may only need the window moved up, not a full emergency-change process. A “Known” ransomware flag on an internet-facing, unpatched system is the clearest case for skipping straight to emergency change.

When a new KEV drops, do this in the next 24 hours

  1. Hour 0–1: Confirm the entry against the official CISA feed or catalog page — don’t act on a secondhand summary alone.
  2. Hour 0–1: Check knownRansomwareCampaignUse. If “Known,” notify incident response in parallel with change management, not sequentially.
  3. Hour 1–3: Query your CMDB/asset inventory for every instance of vendorProject/product. Produce a count, not an estimate.
  4. Hour 1–3: Pull the vendor advisory linked in notes and confirm whether a patch, workaround, or “discontinue use” is the requiredAction.
  5. Hour 3–6: Draft the CAB pre-read using the five-part template above. Route it to CAB chair and system owners immediately — don’t wait for the next scheduled meeting.
  6. Hour 6–12: Decide standard vs. expedited vs. emergency change based on internet exposure, ransomware flag, and days remaining until dueDate.
  7. Hour 12–20: Get sign-off and schedule the change window, including a rollback plan and a compromise-assessment step if ransomware use is “Known.”
  8. Hour 20–24: Log the CVE ID, dateAdded, dueDate, decision, and owner in your change record. If your organization tracks operational resilience metrics under DORA or similar frameworks, this record is your evidence trail.

Sources

#cisa-kev #vulnerability-management #cybersecurity #patch-management

Published July 21, 2026.