CISA KEV Catalog: How to Use Known Exploited Vulnerabilities Data

The CISA KEV Catalog is not a patch list. It is a list of exploitation evidence that should force a faster, better local decision.

A vulnerability entering KEV means CISA has reliable evidence that attackers used it in the wild. That fact should outrank a generic severity label. It does not prove your organization owns the affected product, runs the vulnerable version, exposes the service, or can deploy the fix without breaking production.

Good teams use KEV to open an urgent evidence lane. Bad teams turn every catalog match into a critical ticket and call the queue prioritized. The first model creates decisions. The second creates another reason for engineers to distrust security work.

What is the CISA KEV Catalog?

The CISA Known Exploited Vulnerabilities Catalog is a public list of CVEs that have been exploited in real attacks. CISA maintains it for federal civilian agencies and recommends that every organization use it as an input to vulnerability prioritization. The word input matters. CISA supplies global threat evidence, not a view of your assets.

CISA publishes the catalog as a web page, CSV, JSON, and JSON Schema. Each record includes the CVE ID, vendor, product, vulnerability name, date added, short description, required action, federal due date, ransomware use field, notes, and related weaknesses. The live official KEV JSON feed is the better source for automation because its fields are structured and its catalog version is explicit.

Inclusion is deliberately narrow. CISA requires an assigned CVE, reliable evidence of active exploitation, a clear remediation action, and relevance to federal interests. Read the official KEV inclusion criteria before treating absence from the catalog as evidence of safety. A CVE can be dangerous and still fail one of those conditions.

What does a KEV entry prove?

It proves observed exploitation at CISA's evidence threshold. That is stronger than proof of concept code, a social media claim, or a high CVSS Base score. It also changes the first question. Instead of asking whether exploitation is plausible, ask where the affected condition exists and what attackers can reach from it.

KEV does not prove exploitation happened in your environment. It does not describe every campaign, target, prerequisite, or reliable indicator of compromise. The ransomware field is also not a complete threat report. A value of Unknown means CISA has not marked known ransomware use in that field. It does not mean ransomware groups avoid the vulnerability.

Catalog absence proves even less. CISA cannot list a flaw without a CVE, and its remit is not to catalog every exploited weakness on every unsupported product. Use KEV as a high confidence escalation signal. Keep EPSS probability, trusted campaign reporting, vendor advisories, and local telemetry in the broader evidence model.

What changed with CISA BOD 26-04 in 2026?

On June 10, 2026, CISA issued Binding Operational Directive 26-04. It revoked and replaced BOD 22-01 and BOD 19-02 for federal civilian agencies. Older articles that present BOD 22-01 as the current federal rule are now stale.

The new directive determines urgency from four variables: whether the asset is publicly exposed, whether the CVE is in KEV, whether an adversary can automate exploitation, and whether exploitation yields partial or total control. CISA publishes the last three inputs. The agency has to determine exposure from its own asset data.

That is a material improvement in operating logic. A KEV on a public system can demand remediation or mitigation plus forensic triage within three calendar days under the directive's highest risk path. Moving the asset off the public internet can change the required timeline, but it does not close the underlying vulnerability.

Private companies are not automatically bound by a federal directive. They should still notice the design. CISA stopped using one fixed catalog deadline and joined exploitation evidence to asset exposure and technical impact. Your policy should be at least that honest about local risk.

How large is the CISA KEV Catalog now?

The official feed released July 29, 2026 contains 1,656 vulnerabilities across 276 named vendors. Of those, 332 carry Known in the ransomware campaign field. The catalog added 265 records from July 31, 2025 through that release date. Those are calculated directly from catalog version 2026.07.29, not copied from a dashboard that can drift away from the source.

That volume argues for automation, but not blind ticket creation. Two hundred sixty five additions in twelve months is about 22 new CVEs a month. A daily pull and match is easy. Proving affected state, identifying the deployable fix unit, and assigning a change owner are the work.

Compare the 1,656 catalog entries with the far larger universe of published CVEs. KEV is selective by design. It is excellent at saying, “attackers have used this.” It is not built to say, “attackers will use nothing else.” Our guide to vulnerability exploitability versus severity explains why direct evidence should win without becoming the only evidence.

How do you ingest and filter the KEV JSON feed?

Pull the source daily, retain the raw response, and store the retrieval time and catalog version. Fail the job on HTTP errors. A silent HTML error page saved as JSON can leave your queue stale while every dashboard stays green.

This command lists entries added during the last twelve months of this run. The field names come from CISA's feed, and the filter uses the official jq select and array syntax:

curl -fsSL \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r --arg since '2025-07-31' '
      .vulnerabilities[]
      | select(.dateAdded >= $since)
      | [.cveID, .dateAdded, .dueDate, .knownRansomwareCampaignUse]
      | @tsv'

Production ingestion needs four more controls. Validate the response against the schema. Compare catalogVersion with the last accepted version. Alert when the feed becomes stale. Preserve changed records, not just new CVE IDs, because required actions and notes can change after the first addition.

Join on CVE ID only after your scanner or inventory has produced a credible affected instance. A catalog record is global. Your operating record should include asset ID, observed product and version, service state, network route, owner, business service, fix unit, and the evidence time for each fact.

How should KEV change a remediation workflow?

Give every KEV match an urgent validation timer, not an automatic critical verdict. The first owner confirms affected state. The second confirms exposure and consequence. The change owner chooses patching, mitigation, removal, or a controlled exception. A final check proves that the affected condition or exploit path is gone.

Consider a fleet with 640 KEV matched instances. Grouping identical versions under shared deployment rings turns them into 73 remediation actions. Endpoint evidence shows that 19 actions are false matches or inactive packages. Fifteen remaining actions affect public systems. The team can safely deliver 12 changes this week.

The math forces an executive choice. Twelve available slots minus fifteen public actions leaves a deficit of three. Leadership can add an emergency window, remove exposure on three services, or accept documented risk. Calling all 640 instances critical does not create one extra change slot.

Feed the validated actions into the vulnerability prioritization operating model. Use the threat intelligence prioritization workflow when campaign relevance or exploit behavior needs to break a tie inside the KEV lane.

Should every KEV vulnerability be priority one?

Every credible local KEV match deserves rapid attention. It does not follow that every match has the same response. An internet gateway with total control impact and a working exploit path belongs ahead of an isolated test image scheduled for deletion tomorrow.

Do not let local context erase exploitation evidence. Context should choose the action and timeline, not invent a reason to ignore an uncomfortable fact. A compensating control needs a tested path interruption, an owner, an expiry date, and a trigger that returns the item to the urgent lane.

EPSS remains useful for non KEV CVEs and for ordering investigation when many new findings arrive. A low EPSS score must not overrule confirmed exploitation. The older CVSS and EPSS comparison shows why severity, probability, and evidence should stay visible rather than collapse into one unexplained number.

What should happen when a KEV record changes?

Treat the feed as versioned evidence, not a static block list. A CVE can enter the catalog after it already exists in your scanner data. Required actions, notes, and ransomware use can also change after the first addition. Reconcile the full current record against open and closed findings on every accepted feed version.

Save the prior value, new value, retrieval time, and jobs affected by the change. If a note adds forensic guidance, the update may reopen work even when patch deployment already finished. If a required action changes from patching to discontinuing a product, the old closure no longer answers the current instruction.

Do not infer that a missing record means CISA withdrew the exploitation evidence. Feed failures, parser defects, and schema changes are more likely explanations. Quarantine the update, compare counts and catalog versions, and require a data owner to approve any large removal before downstream systems close work.

Keep closed actions searchable by CVE, catalog version, asset, and proof. When the same CVE returns through a rebuilt host or newly acquired business unit, the earlier record can show the approved fix, verification query, outage history, and owner. That turns yesterday's response into usable operating knowledge instead of another ticket archive.

Which KEV metrics reveal whether the process works?

Count time to affected state confirmation, not just time to ticket creation. Then measure public KEV actions open, remediation or mitigation time, exception age, verification failure rate, reopened actions, and catalog freshness. These measures expose the handoffs where risk waits.

Closure rate alone is weak. A team can close a ticket when a patch job reports success while the vulnerable version remains loaded. Verification failure rate catches that problem. Reopen rate catches assets that drift back. Exception age catches temporary controls that became permanent through neglect.

Artemes uses deep endpoint context with AI driven analysis to connect public vulnerability evidence to actual system state and exact remediation guidance. Whatever platform you use, keep the facts visible. An operator should be able to explain why the item entered the urgent lane, what changed, and how the team proved the result.

Frequently asked questions

Is the CISA KEV Catalog only for federal agencies?

The binding directives apply to federal civilian agencies. The catalog is public, and CISA urges all organizations to use it as a prioritization input.

How often does CISA update KEV?

CISA updates the catalog as qualifying evidence arrives. Pull it daily and monitor its released date rather than assuming a fixed weekly schedule.

Does KEV replace EPSS or CVSS?

No. KEV records confirmed exploitation evidence. EPSS forecasts observed exploitation over the next 30 days. CVSS describes technical severity. Local priority needs those signals plus affected state and consequence.

What should happen when a KEV patch cannot be deployed?

Reduce exposure, apply a tested compensating control, perform any required forensic triage, name the approver, set an expiry, and keep the permanent fix in the owned queue.

Executive takeaway

Pull KEV daily. Open a fast validation lane for every local match. Join exploitation evidence to affected state, exposure, consequence, change capacity, and verification. Then make deficits visible to leadership. The next action is simple: take the latest catalog, match it to one production inventory, and time how long your team needs to produce a verified list of affected owners. That elapsed time is the first metric to fix.