CISA Said 'Known Exploited' on Monday. The Exploit Had Been on GitHub for Twelve Days, and Nobody Has Ever Scanned Us for It.
- Patrick Duggan
- 2 hours ago
- 5 min read
When CISA adds a CVE to the Known Exploited Vulnerabilities catalogue, the date it stamps on that entry is the day CISA could confirm exploitation. Everybody reads it as the day exploitation started. Those are not the same clock, and the gap between them is where your patch window actually lives.
We can measure the gap, because we happen to keep both clocks running.
The three columns
For every CVE in KEV we hold, or can hold, three dates.
t0 — the KEV listing. CISA's, public, unambiguous.
t1 — the first public proof-of-concept our GitHub watch saw. Ours. An exploit harvester has been indexing public exploit repositories continuously since April; it has seen 1,053 distinct CVEs.
t2 — the first probe against our own sensors for that vulnerability. Also ours, and the reason this analysis is not reproducible from public data alone. An edge honeypot has taken 78,159 events from 3,118 distinct addresses across 725 networks since 5 April.
All three columns exist for 139 KEV entries. That number is the denominator and it stays in every sentence below, because 139 of 1,666 is what we can actually speak to — the other 1,527 are unknown, not slow, and the difference matters more than the finding.
Eighteen were already armed when CISA listed them
For 18 of those 139, our harvester had indexed a working public exploit before the KEV listing date. Not a rumour, not a vendor advisory — a repository anyone could clone.
The tail is long: 85 days for an Apache Tomcat flaw, 58 for Langflow, 36 and 27 for two separate Fortinet FortiSandbox issues, 29 for Progress LoadMaster, 17 for Ubiquiti UniFi OS, 14 each for an IBM Langflow issue and an Oracle E-Business Suite one, 12 for Cisco Unified Communications Manager.
The median across all 139 runs the other way — 193 days from KEV listing to the first public PoC we see. That is the reassuring number, and it is the one that makes the 18 dangerous. If your mental model is "KEV lists it, then eventually exploit code shows up," you are right most of the time and catastrophically wrong on the tail, and nothing in the KEV entry itself tells you which case you are in.
Monday's example, with both receipts
CISA added a Microsoft SharePoint flaw to KEV on 18 August.
A public exploit repository for it was created on 6 August and last updated on the 10th — fifty-three stars, published by a researcher at a commercial security vendor, entirely above board. Our harvester indexed it on the 11th, along with the request paths it targets.
So on the morning CISA told the world this was known-exploited, the exploit had been publicly available for twelve days, and had been sitting in our feed for seven.
We did not find that exploit. Someone else wrote it and published it openly, and we were five days behind the repository appearing. The lead we are claiming is not discovery — it is the seven days between our index and the official listing, which is the only claim the receipts support. That distinction is the entire discipline: a lead you cannot date on both ends is a feeling.
The part that changes what you patch
Here is where the honeypot column earns its keep.
Of those 139 CVEs, 132 have a public exploit and have never once been probed for against our sensors. Not rarely. Never.
Meanwhile our sensor's actual traffic looks like this: 24,840 WordPress probes. 21,821 attempts at environment-credential files. Then a long drop to 770 for exposed git directories, 467 for GraphQL introspection, 219 webshell hunts, 214 Spring Actuator, 83 phpMyAdmin.
The enterprise products that dominate KEV — the firewall appliances, the VPN concentrators, the collaboration servers, the virtualisation stacks — generate zero broad scanning against us. Zero for Cisco, zero for Fortinet, zero for Ivanti, zero for VMware, zero for Exchange, zero for SharePoint.
That silence is a finding, not a gap in the data. It separates two populations that vulnerability management routinely treats as one:
Commodity mass-exploitation is a firehose pointed at everything with an IP address, and it is overwhelmingly aimed at WordPress and leaked credentials. It will find you because you exist.
Targeted exploitation is aimed at named organisations running specific appliances. It does not sweep, so a sensor that is nobody's target never sees it — which is exactly why our zero for those products means our sensor did not see it, and never nobody is being exploited. Those CVEs are in KEV precisely because somebody was.
The practical consequence is uncomfortable for a patch queue sorted purely by KEV membership: the vulnerabilities most likely to be scanned for at your perimeter tomorrow are not the ones at the top of that list. They are the boring ones, in the software you forgot was installed, on the box nobody owns.
What we are not claiming
We cannot tell you the true weaponisation rate. We can tell you it for the 139 CVEs where our harvester and our sensors both have something to say, and every figure above carries that denominator on purpose.
We are also not the source of most of what we redistribute. Our feed is 84,431 first-party indicators against 287,186 redistributed from public feeds — 23% ours. Redistribution is distribution value to defenders who cannot afford a vendor; it is never our detection, and we say so in the API response itself rather than in a footnote.
Source addresses from the sensor are deliberately never served. An observation set is not a target list.
Confidence capped at 95%, as always. Something in here is wrong; we would rather you know which parts we can defend.
If you take one thing
Stop reading the KEV date as the start of the exposure window. It is the date the window became officially visible, and for one in eight of the entries we can measure, it had already been open for weeks. Then go and look at what is actually knocking on your edge, because there is a very good chance it has nothing to do with the CVE at the top of your queue.
The three columns behind this post are served live at analytics.dugganusa.com/api/v1/first-party — denominators, disclaimers and all. If this was useful, or if you think we have it wrong, there is a one-click rating at the bottom of this page; it is the only direct signal we get from readers, and we read every one.
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.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=two-clocks-kev-weaponization-latency-and-what-actually-scans-you
Comments