What does the KEV notes field link to, and should you read it?

The KEV notes field holds the reference links for each entry, and in the 2026.10.16 feed all 1,748 entries had one that included an NVD link. Many also link to the vendor advisory. For a research post, notes are where you find the primary source behind a claim.

What is in the field

The KEV JSON schema gives each vulnerability a notes string. In the snapshot fetched on 19 October 2026, none were empty, and each contained at least one URL. Links are separated by a semicolon and a space, so a short pattern can pull them out.

The author counted entries by the host named in the notes, counting each host once per entry:

Most entries carry one or two links; 773 had exactly one and 684 had two, with the rest holding three or more. That tells you the NVD link is the common denominator and the vendor link is where the product specific detail lives.

Why this matters for a data post

A claim such as "this product was exploited" is strongest when a reader can click through to the vendor's own statement. The notes field makes that cheap. Use it three ways:

1. Cite the vendor advisory for any entry you discuss in prose, not just the KEV row.
2. Check that the link still resolves when you publish. Third party pages move.
3. Treat the notes as pointers, not as evidence of exploitation. The KEV listing is CISA's statement; the vendor page describes the flaw and the fix.

The CC0 license file CISA distributes with the catalog adds one caution: information at third party links is bound by those sites' own policies and licenses. So the catalog data is free to reuse, but the pages it links to are not automatically so. For the full question, see the attribution checklist for KEV, EPSS and OSV.

A short extraction recipe

import json, re
rows = json.load(open("kev.json"))["vulnerabilities"]
for r in rows[:3]:
    print(r["cveID"], re.findall(r"https?://[^\s;]+", r["notes"]))

Check the pattern against a few rows by eye, since notes sometimes contain trailing punctuation. Report how many URLs you extracted and how many entries had none.

Limits of the notes field

The field is free text. A host count depends on your pattern, and some entries mention a URL inside a sentence. Say so in the methodology. Do not infer anything about a vendor's responsiveness from how often its host appears; Microsoft's count reflects how many Microsoft entries exist, not how fast it publishes advisories.

A worked example of using notes as evidence

Say you want to write a sentence about a specific entry. The KEV row tells you the vendor, product, name and date added. The notes field then gives you the places to read more. A careful workflow looks like this.

1. Pick the entry and read its notes string.
2. Open the vendor link first, if there is one, since it is the vendor's own description.
3. Open the NVD link to see the CVE record, any score and the references list.
4. Compare the product and version wording across the three. If they differ, report the difference rather than choosing one.
5. Cite the vendor page for the product detail and KEV for the exploitation listing.

This takes a few minutes per entry and keeps each claim tied to the source that makes it. KEV supports the sentence "CISA lists this as exploited". The vendor page supports "this is the affected product and the fix". Neither supports the other's claim.

Counting links without fooling yourself

Because the NVD link appears in every entry, a host count shows 1,748 for nvd.nist.gov. That is a property of how the catalog is built, not a finding. The interesting counts are the vendor hosts: 135 entries reference msrc.microsoft.com and 53 reference support.apple.com. Those numbers describe the catalog's make up, and they mostly track how many entries each vendor has.

A fair method: count each host once per entry, say so, and give the extraction pattern. Repeat the count on a hand checked sample of ten rows. If the sample disagrees with your script, fix the pattern before publishing.

Link rot and when to check

Third party pages change. A link in the notes that resolved on the day of your download can move later. If a link supports a claim in your post, open it on the day you publish, and keep a saved copy of the part you rely on, if the page's terms allow it. If it no longer resolves, say so, rather than leaving a dead citation. This is also a good moment to record the snapshot, as in freeze a dataset.

What notes will not tell you

The notes field does not say how a vendor learned of exploitation, how many systems were affected, or who was targeted. Do not infer any of that from the presence of a link. It simply lists where to read more.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a finding links to a fixed version, which is the kind of vendor information the KEV notes point you toward.

Quick check

Sources

• CISA KEV JSON feed, catalogVersion 2026.10.16, https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (fetched 19 October 2026; host counts computed by the author).
• CISA KEV license file, https://www.cisa.gov/sites/default/files/licenses/kev/license.txt (fetched 19 October 2026).
• CISA, Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (fetched 19 October 2026).

Last reviewed: 19 October 2026.