CISA's Must-Patch List Is a Lagging Indicator. We Measured By How Much: 31 of 189 Entries Were Already Armed Before the Listing.
We re-ran our weaponization-latency measurement this morning. It correlates two dates for every CVE in CISA's Known Exploited Vulnerabilities catalog: the day CISA added it, and the day our exploit harvester first saw public proof-of-concept code for it on GitHub.
Thirty-one of the 189 entries we can actually measure already had working public exploit code before CISA listed them. The furthest ahead was 97 days.
The denominator is the honest part
The KEV catalog holds 1,758 entries. Our harvester has seen public exploit code for 1,561 CVEs. The overlap — the set where we can date both ends and therefore say anything at all — is 189.
We are not telling you that 31 of 1,758 KEV entries were pre-armed. That would be a much better-sounding number and a much worse claim, because the other 1,569 are not evidence of anything except that we cannot date them. A ratio without its denominator is a sales figure, not a measurement.
So: 31 of 189. Sixteen point four percent of the KEV entries we can measure were already weaponized when CISA told you to patch them.
It held when the sample doubled
We published this measurement in August at 17 of 90. Since then the measurable set has more than doubled, and the rate barely moved — 18.9 percent then, 16.4 percent now.
That matters more than either number. A finding from a sample of 90 is a hypothesis. A finding that survives the sample doubling is a property of the catalog. The second run is the one that makes the first run worth anything, which is exactly why we re-ran it instead of citing August.
The leaders, in days before the listing: Kludex Starlette at 97, Apache Tomcat at 85, Kestra OSS at 64, Langflow at 58, Fortinet FortiSandbox at 36, Cisco Secure Firewall Management Center at 32.
Langflow is the one to sit with. It has now hit the KEV list four times. Its first appearance was already 58 days behind public exploit code. If your prioritization process begins when CISA publishes, you began that one two months late, four times.
The other half of the catalog is the part nobody looks at
Here is the figure we did not expect: 173 KEV entries have public exploit code and have drawn exactly zero probes against our sensors.
For context on what commodity scanning actually looks like, our edge has logged 59,243 WordPress probes and 45,204 Laravel probes since April. Against the 173, nothing. Not a low number — zero.
An exploit that is public, listed as known-exploited, and never once fired at a broadly-exposed sensor network is not being used for spray-and-pray. Somebody is holding it for targets they picked. That inverts the usual reading of quiet: on this list, silence is not safety, it is selection.
We will say the careful thing here, because it is the honest one: absence in our sensor data means our sensors did not see it. It does not prove nobody was scanned. But 173 entries with public code and zero commodity traffic is a population worth separating from the WordPress noise, and almost nobody separates it.
What this changes about patch order
The median gap from KEV listing to the first public PoC we can date is 114 days across all 189. Most of the catalog genuinely is ahead of the exploit, and the system works as designed.
The 31 are the exception that should drive your process, because for those the window was already shut on the day the clock officially started. Treat the KEV due date as a compliance deadline, which is what it is, and treat exploit availability as the operational one. They are not the same date and this measurement is how far apart they drift.
How to use our platform to get ahead of this
None of the above is useful to you as an article. Here is how to run it against your own stack, starting with the part that needs no account at all.
Check any CVE yourself, free and anonymous. Request analytics.dugganusa.com/api/v1/dredd/kev-gap with a cve parameter — for example cve=CVE-2026-21962, the Oracle WebLogic proxy bug. You get back the KEV listing date, the CISA due date, the vendor and product, and our first sighting with a gap in days and a direction of AHEAD or BEHIND. For that Oracle CVE it returns our first indicator on August 8 from source exploit-harvester, fifteen days ahead of the listing. No key, no signup, no rate card. Paste in the CVEs on your current patch queue and see which ones were already armed before you heard about them.
Pull the blocklist into whatever you already run. The feed is at analytics.dugganusa.com/api/v1/stix-feed/ips.csv, with domains.csv and hashes.csv alongside it. It needs a free API key — registration costs nothing and the free tier is ten queries a day, which is plenty to wire up a daily pull. It drops into Sentinel, Splunk, a firewall object group, or a cron job and a text file. Set min_confidence as a query parameter to pick your own floor; we publish the score and you decide where to block, because your tolerance for a false positive is not ours to set.
Ask the corpus directly. analytics.dugganusa.com/api/v1/search takes a q parameter and an index — iocs for indicators, cisa_kev for the catalog, blog for our written research. The threat-intel/enrichment endpoint takes an ip parameter and tells you what we hold on it and from which lane. Both need the same free key.
Check the live corpus size before you believe any number we publish, including the ones in this post. analytics.dugganusa.com/api/v1/search/stats is anonymous and returns the real document counts per index. We would rather you verified us than trusted us.
If you run AI agents, point them at the MCP server. Our Jeevesus server exposes the same corpus as agent tools — search, indicator enrichment, dependency checks against a malicious-package deny-list, and KEV vendor-risk and exploitation-stickiness lookups for patch prioritization. Read-only, no auth, and every result cites its source.
The whole point of measuring the gap is that somebody can act inside it. If your Langflow, Tomcat or Starlette instances are on the list above, the useful next move is not to read further — it is to check those four CVEs against the kev-gap endpoint and see what your own exposure window actually was.
Ninety-five percent
Five percent of this is wrong somewhere and we would rather name where we think it is.
The likeliest error is in the PoC dates. Our harvester records when it first saw public exploit code, not when that code first existed. A repository created quietly and found by us a week later dates to our sighting, which makes every gap in the 31 a conservative floor rather than a precise figure. The direction of that bias favors the catalog, not us.
The second is the 173. Zero probes against our sensors is a statement about our sensors. We run a real edge with real exposure, but it is not the internet, and a targeted campaign aimed at four hospitals would be invisible to us by design. We report it as a candidate population and not as proof of targeting.
The third is the catalog itself. CISA lists what CISA can confirm. An entry's absence from KEV is not evidence that nothing is being exploited.
If this was worth your time — or if you came for something and did not find it — tell us in thirty seconds at analytics.dugganusa.com/nps.html. No cookies, no tracking, no third parties, and your address is hashed and never stored.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments