To cite a CISA KEV number, quote four things from the JSON feed itself: the catalogVersion, the dateReleased timestamp, the count field, and the date you fetched the file. Add a SHA-256 hash of the file you used. Without those, a KEV figure cannot be checked a week later.
Why a bare KEV number is hard to verify
The Known Exploited Vulnerabilities catalog grows. CISA describes it as the authoritative source of vulnerabilities exploited in the wild and asks organizations to use it as an input to prioritization. A sentence such as "KEV has about 1,700 entries" is true on one day and stale on another, and it gives a reader nothing to compare against.
The feed already carries the metadata you need. On 19 October 2026 the top of the JSON file read:
{
"title": "CISA Catalog of Known Exploited Vulnerabilities",
"catalogVersion": "2026.10.16",
"dateReleased": "2026-10-16T17:15:48.8752Z",
"count": 1748,
"vulnerabilities": [ ... ]
}
The four fields to record
| Field | Where it comes from | Why it matters |
|---|---|---|
| catalogVersion | Top of the JSON feed | Names the release you analyzed |
| dateReleased | Top of the JSON feed, UTC | Shows how fresh the release was |
| count | Top of the JSON feed | A quick sanity check against your own row count |
| Fetch date | Your own log | Shows when you downloaded it, which can differ from the release date |
On the fetch date above, the release was three days old. That is normal, since the catalog only changes when CISA publishes an update. Recording both dates avoids the impression that the data is current to the hour.
Check the count against your own parse
Your parser should confirm that the count field equals the number of objects in the vulnerabilities array, and that the CVE IDs are unique. In the 2026.10.16 release, the count field said 1,748, the array held 1,748 objects, and 1,748 distinct CVE IDs appeared. If those three numbers ever disagree, say so in your write-up, because it means a parsing or feed problem rather than a finding.
A citation line you can copy
Put this near the figure, not buried in an appendix:
Source: CISA Known Exploited Vulnerabilities catalog, JSON feed, catalogVersion 2026.10.16, released 2026-10-16T17:15:48Z, 1,748 entries, fetched 19 October 2026, SHA-256 b6e27975f663...d357d.
Link the catalog page itself so readers can find the current version and compare. For hashing and storing the file, see how to freeze a vulnerability dataset.
What a citation does not do
A catalog version tells readers which data you used. It does not tell them whether KEV is the right dataset for your question. KEV lists vulnerabilities that CISA has evidence were exploited; absence from the list is not evidence of safety. For that caveat, read what KEV, EPSS and exploit databases cannot tell you.
A worked example, start to finish
Suppose you want to write "KEV holds 1,748 entries". Here is the full chain you should be able to show.
- Download the JSON feed and note the time in UTC.
- Read the top level fields: catalogVersion 2026.10.16, dateReleased 2026-10-16T17:15:48Z, count 1748.
- Parse the vulnerabilities array and take its length. It was 1,748.
- Collect the cveID values into a set. It also had 1,748 members, so each entry is a distinct CVE ID.
- Hash the file and store the hash with the file.
- Write the sentence with the version, the release date and your fetch date.
Only after step 6 is the number ready to quote. Each earlier step is a cheap check that catches a different mistake: a truncated download, a parser that skips rows, or a duplicated entry.
What to do when your number moves
If you rerun the script a week later against the live URL, the count will probably be higher and the catalogVersion will be new. That is not an error. It means the catalog has been updated. Keep the old snapshot, publish the old figure with its version, and describe the new one as a separate data point. Writing "KEV grew from 1,748 to N" is only valid if both numbers carry their own versions.
A common trap is editing a post's number in place and leaving the old citation line. Readers then see a figure that does not match the stated version. Change both together, and add a dated note, as described in keeping a corrections log.
Where the citation belongs
| Place | What to include |
|---|---|
| Chart caption | Version, release date, fetch date |
| Table footnote | Version and counting unit |
| Methodology section | Full detail plus the hash |
| Social or summary text | Version in a short form, such as "KEV 2026.10.16" |
The shorter the format, the more important the version string, because it is the one piece that lets a reader find the exact release. See the methodology template for how this fits into a full write-up.
Common mistakes
- Quoting the count from the catalog web page and the percentages from your own parse of a different download.
- Citing the page URL only. The page changes with every release.
- Leaving out the fetch date because "the release date is enough".
- Rounding the count in prose and then showing the exact number in a table, which makes the two disagree.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings change between scans, which is the same reason a dated snapshot matters for any statistic.
Quick check
Is the fetch date different from the release date?
Yes. dateReleased is when CISA published that version. The fetch date is when you downloaded it. Record both.
Do I need the hash if I record the version?
The version names the release. The hash proves the file you analyzed is the one you describe, which helps if a copy is later edited or truncated.
Does a KEV count tell me how many vulnerabilities are exploited?
No. It tells you how many entries CISA has listed in that release. Exploited vulnerabilities that are not listed do not appear.
Sources
- CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026).
- CISA KEV JSON feed, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (fetched 19 October 2026; counts computed by the author from the file).
Last reviewed: 19 October 2026.