What Do KEV Catalogs Actually Know? Evidence, Lead Time and Zero-Days Across Five Catalogs

A Known Exploited Vulnerabilities (KEV) catalog is a list of vulnerabilities somebody asserts are being exploited in the wild. CISA publishes the best-known one. Vulnerability-Lookup aggregates five of them on its public instance — CISA KEV, the ENISA catalog, The Shadowserver Foundation’s honeypot observations, Previdian’s aggregation, and CIRCL’s own catalog — all expressed in the same GCVE BCP-07 format, so that they can be compared rather than merely browsed.

Since June, the KEV catalogs page has shown which catalog lists which vulnerability. This post is about two new sections that answer the next two questions: why does a catalog say a vulnerability is exploited, and when does it say so relative to everything else we know about the vulnerability? Along the way they surface a population that is easy to overlook: vulnerabilities listed as exploited before their CVE was even published.

The comparison page in one paragraph

For readers who have not opened the page: it stacks several views of the same merged set of vulnerabilities, each answering one question.

• Catalog overlap — a pairwise heatmap: how many vulnerabilities two catalogs share, and the Jaccard similarity between them.
• Coverage timeline — the cumulative number of vulnerabilities each catalog has listed over time, so bulk imports and the birth of each catalog show up as steps.
• Coverage lead time — for vulnerabilities carried by several catalogs, which catalog tends to list them first, and by how many days.
• Blind spots — for each catalog, the vulnerabilities the other catalogs flag as exploited but it does not carry, with the count corroborated by two or more catalogs.
• Catalog combinations — an UpSet plot of exactly which combination of catalogs each vulnerability belongs to.
• Catalog coverage — the matrix itself: one row per vulnerability, one column per catalog, searchable and paginated over the whole set.

Every chart drives the table: click a column of the UpSet plot, a catalog in the blind spots, or now a bucket in the sections below, and the coverage table filters to those vulnerabilities.

Evidence behind the listings

BCP-07 does not just let a catalog say “exploited”. Each entry carries evidence records, each typed by how the exploitation was established, and each carrying a signal stating how far the claim goes and a confidence. The types fall into two families:

• first-hand observation: the asserting party saw it happen — a honeypot, a sinkhole, telemetry, an incident response;
• reports: the asserting party relays somebody else’s account — a vendor advisory, a CSIRT report, a public report, a research report.

The new Evidence behind the listings section reads those records across all catalogs.

The first thing the per-catalog bars show is that each catalog is essentially one kind of sensor. CISA’s entries rest on vendor reports, Shadowserver’s on honeypot observations, ENISA’s on CSIRT reports, Previdian’s on public reports. Only CIRCL’s hand-curated catalog mixes types: sinkhole observations, an incident response, a public report. This is not a flaw in the catalogs; it is what they are. It does mean that no single catalog can tell you whether a vulnerability has been both observed being exploited and reported as such by someone with access to the affected systems.

The aggregation can. Across the 2,935 vulnerabilities on the public instance:

• 42% are backed by both first-hand observation and reports,
• 55% by reports alone,
• 3% by observation alone.

That 42% is the population with the broadest corroboration: both first-hand observation and reporting evidence behind the same vulnerability. It is a property of the ecosystem of catalogs, not of any one of them. The “Observed and reported” bucket is clickable and lists those vulnerabilities in the coverage table.

The strongest signal ladder reads the same records the other way round. For each vulnerability, it keeps the firmest claim any catalog makes, from an exploit merely being available up to a confirmed compromise. It ranks the strength of the evidence signal as the catalogs state it, not an independently verified ground truth. On the public instance 86% of vulnerabilities top out at successful exploitation, 11% reach confirmed compromise, and 3% only have in-the-wild attempts behind them — the honeypot population, where an attempt is what a honeypot can see.

The vulnerabilities behind the listings

The second section leaves the catalogs’ own records and looks at what the CVE records and today’s EPSS scores say about what each catalog lists.

Age at listing

For each catalog, the strip shows the distribution of days between a CVE’s publication and the catalog’s listing of it: the box spans the middle half of the catalog’s entries, the tick is the median. The catalogs have strikingly different reflexes:

Shadowserver lists late because honeypots catch the mass exploitation of old flaws — the long tail of internet-facing devices that never got patched — and it almost never precedes publication. CISA and Previdian have long tails too, but also a substantial population listed before the CVE was published. Those are the cases where the catalog listing predates CVE publication — a population that includes vulnerabilities exploited before public disclosure, but also vulnerabilities whose vendor advisory and catalog listing simply preceded a slow CVE record, and a few whose catalog dates were set after the fact.

Time to first listing

The middle panel asks the ecosystem-level question: for a CVE published in a given year, how long until any catalog listed it? Among the vulnerabilities already listed, the median falls from 923 days for CVEs published in 2019 to 7 days for CVEs published in 2026, and the share listed within a week of publication rises from 9% to 51%.

Two caveats the chart states itself. The catalogs only started listing in 2019 at the earliest, so a 2015 CVE was listed when a catalog was founded, not when its exploitation began; the chart therefore only covers CVEs published after the earliest catalog started listing. And the recent years are still open: a 2026 CVE that will be listed in 2028 is not in the data yet, so the recent medians will drift upwards. Even so, the direction is unambiguous, and it matches what CISA’s own catalog and the exploitation-timing literature have been showing: the window between disclosure and known exploitation has collapsed.

EPSS today

The right panel places each catalog’s entries on the current EPSS scale, with the share of entries carrying a critical CVSS base score alongside. EPSS predicts exploitation; the catalogs record claims and evidence of it. The two are not measuring the same thing, but the distributions are not as far apart as one might expect: around half of CISA’s and Shadowserver’s entries score 0.5 or above on today’s EPSS scale. The interesting residue is the 135 vulnerabilities listed as exploited while EPSS scores them below 0.01 — cases where prediction and observation disagree, and which a defender relying on EPSS alone would deprioritise. That count is clickable too.

The CVSS column tells another small story: 55% of Shadowserver’s entries and 74% of CIRCL’s are critical, against 35% for CISA. Honeypots see unauthenticated remote code execution; advisories see everything.

Listed before the CVE was published

Back to the number that surprised us most: on the public instance, 102 vulnerabilities were listed by some KEV catalog before their CVE was published. Clicking it filters the coverage table to exactly those.

How can a vulnerability be known-exploited before its CVE exists? Because a CVE identifier is reserved first and published later, and in between the vendor, the reporters and the attackers are not idle. Take the first row, CVE-2026-85706, a path traversal in GitLab:

• the identifier was reserved on 2026-09-04;
• CISA and Previdian listed it as exploited on 2026-09-11;
• the CVE record was published on 2026-09-12.

The vulnerability page tells the rest. Its sightings heatmap can overlay the reservation date, the publication date and the KEV catalog dates on the daily sightings Vulnerability-Lookup collects from social media, threat-intelligence channels and other sources — and the first sightings of this vulnerability predate even the reservation.

This is the ordering that matters for defenders and that the CVE publication date alone hides: discussion, then reservation, then catalog listing, then publication. The dates alone only establish the order; it is the sightings and the catalogs’ evidence that say the vulnerability was being exploited during it. A team that waits for the CVE record to act has, in cases like this one, been the last to know. Comparing catalogs against the record’s own timeline is one way to measure how often that happens; on this instance it is roughly one listing in thirty.

Also on each catalog’s page

Each catalog’s own page received a matching refresh: a summary strip with its size, freshness, recent listings, dominant evidence type and the share of entries other catalogs also carry, and a column showing which other catalogs list each entry. The count of entries only that catalog knows links back to the comparison page.

Try it

Everything above is computed live from the catalogs an instance aggregates, and both sections work for a single catalog too. Explore them on the public instance at vulnerability.circl.lu/kev-catalogs, or run your own: Vulnerability-Lookup is open source, and any BCP-07 catalog — including the one you maintain yourself — takes its place in the comparison.