How many days from a CVE going public to CISA listing it as exploited?

How has the lag changed over time?The series n = 719

Whole UTC calendar days from the CVE record's NVD publication date to the day CISA added it to the Known Exploited Vulnerabilities catalogue. Restricted to the 719 listings the collector calls fresh: catalogued on or after 2022-07-01, and published no more than 730 days before they were catalogued. Both restrictions are judgements about what the catalogue was doing, not statistical corrections, and the unrestricted series is drawn below so the judgement can be checked.

The compression happened between 2022 and 2023 — before the agentic-AI period — and the series has not moved since. Through all four years a quarter of entries were catalogued within a single day of publication.

Every figure the chart draws. n is printed beside each one and the cohorts are small — 42 to 204 entries — so a handful of unusual listings moves a median. "Fastest" and "slowest" are the extremes of the cohort, not outliers that were removed.

Why does the collapse look like a backlog?The artefact

Artefact — do not read this as a trend

Drawn the way a naive analyst would draw it: one bar per half-year, length is the median. It is the same instrument as the chart above, on the same kind of axis, so the two can be compared directly — and the difference between them is entirely which entries were counted.

The artefact's own figures, published so that the claim that it is an artefact can be checked against them. All 1,726 entries are in here, starting with the 311 catalogued in the half-year the catalogue launched on 2021-11-03.

The same calendar years, counted both ways. The left column restricts to listings after the catch-up window and to CVEs published within two years of being catalogued; the right column is every entry. The 2022 rows are not comparable to each other — the left one is half a year (from 2022-07-01) and the right one is all twelve months. There is no left-hand cohort before 2022 because the window begins at 2022-07-01; the cell says so rather than printing a dash.

What was CISA actually cataloguing in 2022-H1?

474 vulnerabilities were catalogued in that half-year. 364 of them had a CVE record older than two years at the moment they were written down, leaving 110 that were published within two years of being catalogued. The oldest record in the window was published 2002-06-25 — CVE-2002-0367, Microsoft Windows, catalogued 2022-03-03: 7,191 d. A filing decision, not an attack.

Each row is the number of CVEs listed in 2022-H1 whose NVD record was published in that year. This is the proof that the naive series is an artefact: a 2022 listing of a 2002 CVE is a filing decision, not an attack.

What does one catalogue entry look like in full?

This is the vulnerability that prompted the measurement. Every row in the catalogue is this arithmetic and nothing more: two dates from two feeds, subtracted.

CVE

CVE-2026-19490

Product

Citrix NetScaler, authentication bypass

NVD record published

2026-08-19

Added to the KEV catalogue

2026-09-09

Lag

21 d

Its cohort

2026, median 8.5 d, n = 204

Published 2026-08-19, catalogued 2026-09-09: 21 days. Unremarkable against a 2026 median of 8 days over 204 listings.

Two numbers for one median, and neither is a rounding error: the 2026 cohort has an even number of entries, so its median is the midpoint of the two middle observations — 8.5 d exactly. The collector also publishes median_days_whole, truncated rather than rounded, so that a printed figure is never larger than the computed one; that field reads 8. This page prints the exact value in its charts and tables, and the sentence above is the collector's own, unedited.

What can this exploit-lag data not do?

Published by the collector, printed here unedited. The first three are the hard ones; the other five are the conventions and exclusions a reader would otherwise have to find in the code.

1. One of the three dateAdded is the day CISA CATALOGUED the vulnerability, not the day exploitation began. This measurement is therefore a lag on a lag: the catalogue's own internal latency is not published, has no reason to be constant across five years, and some unknown part of any movement in this series is CISA getting faster or slower at writing things down. This is the single biggest weakness of the measurement.
2. One of the three KEV records exploitation that the US government observed and chose to publish. It undercounts by an unknown amount, and the amount may vary by vendor, by sector and by year.
3. One of the three 1726 entries is the whole catalogue ever written. The annual cohorts in the headline series are 42 to 204 entries — small enough that a handful of unusual listings moves a median. Every figure is published with its n and must be shown with it.
4. NVD cve.published is when the CVE record was published, which is a dated, checkable proxy for "the vulnerability became publicly known" and is not the same thing. A vendor advisory, an exploit in the wild or a conference talk can all precede it.
5. 65 entries have a negative lag — catalogued before NVD published the record. They are kept in the full table and excluded from the headline series. None is clamped to zero.
6. The 2022 cohort in the headline series is a half-year, not a year. It is labelled as one and its n says so.
7. Restricting to listings after 2022-H1 and to CVEs published within two years of listing is a judgement about what the catalogue was doing, not a statistical correction. The unrestricted series is published alongside it so the judgement can be checked.
8. Nothing here is a forecast. The series stops at the last observation and no line is extended past it.

The collector's instruction to this page, kept: Publish the n beside every figure. The annual cohorts are 42 to 204 entries and a handful of unusual listings moves a median.

Where did this exploit-lag data come from, and how do you recompute it?

CISA Known Exploited Vulnerabilities catalogue and the National Vulnerability Database (NIST). Both are works of the US Government in the public domain. Public domain is not a reason to omit the citation. Every figure must be recomputable, so the source URL and the retrieval date travel with the number. Everything on this page is as catalogued on 2026-09-26; the catalogue changes and these figures are a reading of it on one day, not a standing fact.

How was the join done?

1,726 catalogue entries against 1,726 NVD records on cveID: 1,726 matched, 0 unmatched. Every KEV entry joined. No row is imputed and none is dropped.

NVD publishes a timestamp and CISA publishes a bare date, so both sides are reduced to their UTC calendar date before subtracting. Without that, the answer would depend on what time of day NIST pressed publish. A negative lag is a CVE that CISA catalogued before NVD published its record. Those are real and are kept in the full table; they are excluded from the headline series because they are not an interval between the two events in the order the measurement assumes.

How do 1,726 entries become 719?

The headline series is a subset and this is the whole of the subtraction. Nothing is dropped from the catalogue — the excluded rows are still in the artefact chart above and still in the published file.

Why are quantiles stated at these cohort sizes?

• Median. The textbook median: the middle observation, or the midpoint of the two middle observations when n is even — so an even cohort's median can be a half-day no CVE actually had, which is what a median is.
• Quartiles. Order statistics by nearest rank, sorted[ceil(q*n) - 1]. Always a lag some real CVE had. Never interpolated, because an interpolated quartile is a day count nothing in the catalogue experienced.
• Whole days. median_days_whole is median_days truncated, not rounded, so a printed figure is never larger than the computed one. Both are in the payload; the page may print either as long as it prints n beside it. This page prints the exact value.

What does the catalogue show for scale?

Over every joined entry, for scale. Not a headline figure. Across all 1,726 entries the lag runs from −290 d to 7,191 d, and 65 entries were catalogued before NVD published the record. CISA records a known ransomware campaign for 361 of them and "Unknown" for 1,365. "Unknown" is CISA saying it does not know, which is not CISA saying no, and this page does not print it as one.

How do you recompute it?

Two requests, no key, no pagination, no cache. Fetch both, join on cveID, subtract the UTC calendar dates, and every figure above is that arithmetic and nothing else. The code that does it is collector/exploits.mjs.

1. https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
2. https://services.nvd.nist.gov/rest/json/cves/2.0?hasKev&resultsPerPage=2000

How do you take the table?

The joined table is published beside this page, byte-identical to what the collector wrote — the build copies it verbatim rather than re-serialising, so the checksum of the file in the repository is the checksum of the file served here.

• /api/exploits.json — every number above, plus all 1,726 joined entries as cveID, vendor, product, published, dateAdded, lag_days, ransomware, one row per line. One row per joined entry, sorted by CVE year then sequence. `ransomware` is 1 where CISA recorded knownRansomwareCampaignUse as "Known", 0 where CISA recorded "Unknown", and null where the field was absent. A 0 is CISA saying it does not know, which is not the same as CISA saying no — do not print it as "no".

Time from disclosure to catalogued exploitation · CISA Known Exploited Vulnerabilities catalogue retrieved 2026-09-26 · NVD CVE records for the KEV set (cve.published) retrieved 2026-09-26 · page generated 2026-09-26 19:06:58 UTC · one clock reading, and the retrieval date above is its calendar date rather than a second one.