The CISA Known Exploited Vulnerabilities feed is one JSON file with four top level fields, catalogVersion, dateReleased, count and vulnerabilities, plus a published JSON schema. Each vulnerability has eight required fields and four optional ones. Validate against the schema, check that count matches the array, and key records by cveID.
Where the feed lives
CISA publishes the catalog as JSON at a stable path on cisa.gov, and publishes a matching JSON schema next to it. I downloaded both for this post. The feed's top level carried the title, a catalogVersion, a dateReleased timestamp, a count and the vulnerabilities array. At the time of fetching, the count matched the array length of 1,748 entries.
Fields in each entry
The schema marks eight fields as required. Four more are optional.
| Field | Required | What it means |
|---|---|---|
| cveID | Yes | CVE identifier, pattern CVE then year then 4 to 19 digits |
| vendorProject | Yes | Vendor or project name |
| product | Yes | Product name |
| vulnerabilityName | Yes | Short name of the issue |
| dateAdded | Yes | Date added to the catalog, YYYY-MM-DD |
| shortDescription | Yes | One or two sentence summary |
| requiredAction | Yes | The action CISA lists |
| dueDate | Yes | Date the action is due, YYYY-MM-DD |
| knownRansomwareCampaignUse | No | Known or Unknown |
| forensicTriage | No | Yes or No, per the directive named in the schema |
| notes | No | Free text, often several URLs |
| cwes | No | Array of CWE codes such as CWE-79 |
The schema says Known means the issue is known to have been used in ransomware campaigns, and Unknown means CISA lacks confirmation, not that it never happened.
Validation steps
- Download the feed and the schema together.
- Validate the document against the schema before you trust it.
- Check that count equals the length of the vulnerabilities array.
- Reject any cveID that does not match the documented pattern. Note that the number part can have more than four digits, so do not use a four digit regular expression.
- Parse dates strictly. dateAdded and dueDate are plain dates, and dateReleased is a full timestamp.
- Treat optional fields as optional. Code that assumes cwes exists will crash on entries without it.
Using the feed well
For incremental processing, remember the last catalogVersion you handled and diff on cveID. Do not rely on array order. Store dateAdded as the day CISA added the entry, and keep your own first seen timestamp too, so you can measure how fast you responded.
Separate three questions that the feed blends together. Is the issue in the catalog, which says it has been exploited. Does the product apply to you, which needs your inventory. Is the due date a deadline that applies to you, which depends on your own obligations. The dueDate is the date for the action in the entry. It is not a deadline for every organization.
For matching, the feed names vendor and product in free text, not as package URLs or CPE strings. Expect to map them by hand or by fuzzy matching, and check the notes field for the vendor advisory.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how known exploitation changes the order in which findings should be handled.
Where this fits
The catalog is a strong signal because it records real exploitation. For a deeper look at the numbers, see the catalog growth analysis. Safeguard offers dependency scanning with reachability analysis, and the free scan is a quick first step.
Quick check
Which KEV fields are optional?
According to the published schema, knownRansomwareCampaignUse, forensicTriage, notes and cwes are not in the required list, so handle their absence.
Is dueDate a deadline for every company?
No. It is the due date for the required action recorded in the entry. Whether it binds you depends on your own obligations.
Sources
Last reviewed: 19 October 2026.
