What is exploit lag? How Daily CISO measures time from disclosure to KEV listing

Exploit lag is Daily CISO's measure of how long a vulnerability was public before CISA confirmed it was being exploited: the number of days between a CVE's first publication in NIST's National Vulnerability Database (NVD) and the date CISA added it to the Known Exploited Vulnerabilities (KEV) catalog. It is calculated for every KEV addition in the trailing 45 days.

How it is calculated

Two dates, two owners. The start is the NVD Published Date on the CVE's own NVD record. The end is the Date Added that CISA shows for the same CVE in the KEV catalog. Exploit lag is the difference in days. It is Daily CISO's calculation from those two published fields, not an official CISA or NIST metric.

A worked example: NVD published CVE-2015-3306, a ProFTPD file copy flaw, on 18 May 2015. CISA added it to KEV on 8 October 2026. The exploit lag is 4,161 days.

How to read it

A short lag means a flaw went from disclosure to confirmed exploitation within days, and the patch window was a race. A long lag means an old, often long-patched flaw is still being used against systems somebody never updated. Both call for action, but different action: speed for the first, inventory archaeology for the second.

Zero and negative values occur. NVD and CISA maintain independent records and sometimes publish the same CVE a day apart, in either order. A lag of zero or less means the two dates matched or NVD's record trailed CISA's; it does not mean exploitation preceded disclosure.

What it does not show

The end date marks when CISA had evidence and listed the CVE, not when attackers first used it. CISA's catalog requires reliable evidence that malicious code was executed on a system without the owner's permission, and evidence can surface after the first attacks. The true time to exploitation can therefore be shorter than the lag.

It is not a severity score either. CVE-2015-3306 carries a CVSS score of 10 from CISA on its NVD record, yet it waited more than eleven years for a KEV listing. And the measure covers only CVEs that reach KEV, so it says nothing about flaws that are never confirmed as exploited.

What a patch desk does with it

Sort the table longest first and check each old CVE against the asset inventory: those rows point at the legacy systems attackers are still finding. Then read the shortest lags against the team's own patch speed. Where lags of a few days appear for software you run, a monthly cycle is too slow for the internet-facing copies of it.

Where it appears on Daily CISO

The live table is at exploit lag, built from CISA's KEV JSON feed and the NVD CVE API. Must-patch shows the same KEV additions with due dates and EPSS scores, and the KEV guide explains the catalog's criteria.

Related terms

Known Exploited Vulnerabilities (KEV) catalog, n-day vulnerability, Common Vulnerabilities and Exposures (CVE) and zero-day vulnerability.