Skip to content

Data collected

CVEs Live

Where the data comes from

Four public sources, copied without rescoring. The only decision made here is the order of the lists, and the rule is written below.

Build snapshot collected · KEV catalog 2026.10.02 · EPSS of 2 Oct 2026 · not a live feed: collected once, at build time

CISA Known Exploited Vulnerabilities

cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

Which CVEs are exploited, vendor, product, required action, date added, due date, ransomware use.

Updated by CISA on US business days. US government work, public domain.

FIRST EPSS

api.first.org/data/v1/epss

Probability of exploitation in the next 30 days and percentile, per CVE.

Recalculated by FIRST once a day. Free to use with attribution to FIRST.org.

NVD API 2.0

services.nvd.nist.gov/rest/json/cves/2.0

CVSS assessments (the NVD’s own and the CNA’s), publication and modification dates, CPE product names, recent critical CVEs.

Continuous; analysis of new CVEs can lag by weeks. Public data. This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Program records

cveawg.mitre.org/api/cve/<id>

Description by the CNA, affected versions, references, CNA and ADP CVSS.

Updated when the CNA changes the record. CVE Program terms of use: free with attribution.

The ordering rule

Every list on the site, unless you choose “Newest”, is sorted by the same comparison, applied in this order:

  1. In CISA KEV before not in KEV.
  2. Higher EPSS probability first. A CVE with no EPSS score goes after those that have one.
  3. Higher published CVSS score first, taking the highest among the published assessments.
  4. More recent first: date added to KEV, or publication date.

The rule is one function in the site’s code and is covered by tests, including the case that motivated it: a CVE rated 10.0 that nobody is exploiting must not come before one rated 4.3 that is in KEV.

How collection works

A scheduled job on the site’s edge worker runs every four hours and does one part of the work per run. Every other run it downloads the KEV catalog and rebuilds the list. The runs in between take turns: one asks FIRST for the EPSS of every listed CVE in batches of 100, one asks the NVD for the CVSS and dates of KEV entries, and one asks the NVD for CVEs published in the last 7 days with a CRITICAL rating. The result is stored as one file, /data/kev.json, which the pages read.

So a new KEV entry appears within eight hours, and EPSS scores and recent critical CVEs are refreshed once a day. The NVD limits anonymous clients to 5 requests per 30 seconds, so the job refreshes NVD data for KEV entries one slice per run, asks first for entries it has no NVD data for, and keeps the rest from earlier runs. The window of recent critical CVEs is read one or two days at a time, and the catalog states the days it covers.

Snapshot or scheduled collection

Each page carries a label. Scheduled collection means the catalog came from that job. Build snapshot means the data was collected once when the site was built: the copy bundled with this build was collected on 3 Oct 2026, with KEV catalog version 2026.10.02 and the EPSS model of 2 Oct 2026. Pages of individual CVEs and of weeks are generated at build time and keep the date of that build.

Known limits

  • The watchlist only sees new CVEs that already have a CRITICAL rating on the NVD. A serious CVE that nobody has scored yet does not appear until it is scored or enters KEV.
  • Vendor and product of CVEs outside KEV come from the first CPE in the NVD record, which is missing for many recent CVEs.
  • Affected versions are shown only where the CVE record has structured version data.
  • Lookups in the CVE lookup and the EPSS lookup depend on the CVE Program and FIRST APIs answering your browser at that moment.

Why read vulnerabilities here

Evidence before headline
The default order of every list is: in the CISA KEV catalog first, then EPSS probability, then published CVSS. A 10.0 nobody is exploiting does not outrank a 7.5 under attack.
No score is rewritten
Each CVSS number carries the version and the source that published it. When the NVD and the CNA disagree, both are shown side by side.
Your stack, without an account
The vendor and product filter is stored in your browser and in the page address. There is no sign-up and no server-side profile.
Dated, not "real time"
Every page states when the data was collected, the KEV catalog version and the EPSS model date, and says so when you are looking at a build snapshot.
Take the data with you
RSS and JSON Feed of the KEV additions, filterable by vendor, plus the whole consolidated catalog as one JSON file.

Questions

Does this site decide how severe a vulnerability is?

No. Severity labels and scores are copied from the source named next to them. The only thing decided here is the order of the lists, and that rule is fixed and public: KEV first, then EPSS, then the highest published CVSS, then the most recent.

What happens when a source is unavailable?

The KEV catalog is mandatory: if CISA cannot be read, the previous collection is kept and its date stays on the page. If EPSS or the NVD fail, the affected fields are left empty for that run rather than filled with old or estimated values.

Why is the NVD not the only source for CVSS?

Because the NVD takes time to analyse new CVEs. The NVD API also returns the assessment made by the organisation that assigned the CVE; both are stored and shown, each with its source.

What does "Build snapshot" mean on a page?

It means the numbers were collected once, at the time shown, and shipped with the site, instead of coming from the scheduled collector. A snapshot is real data from the same sources, but it does not update until the next build or collection.

Related sections