We Checked Every CVE CISA Catalogued in the Last Month. All Thirty. We Were Early on Seven, Late on Three, and Had Absolutely Nothing on Seventeen — Here Is the Whole Table.

Threat intelligence vendors publish the wins. Somebody catches one thing early, it becomes a case study, and the case study never mentions the other twenty-nine.

So here is the whole month. Every CVE added to the CISA Known Exploited Vulnerabilities catalog between 28 July and 27 August 2026 — thirty of them — checked against our own indicator index for a receipt that predates the listing. Nothing excluded, nothing selected, no cherry-picking.

Outcome	Count	Share
We had a receipt before CISA listed it	7	23%
Same day	3	10%
Receipt after the listing	3	10%
Nothing at all	17	57%

Median lead on the seven: 16 days. Mean 27.1. Longest 85. Shortest 7.

The seven

CVE	Product	Our receipt	KEV listed	Lead
CVE-2026-34486	Apache Tomcat	11 May	4 Aug	+85 days
CVE-2026-8037	Progress LoadMaster	9 Jul	7 Aug	+29 days
CVE-2026-60004	Gitea	29 Jul	25 Aug	+27 days
CVE-2026-21962	Oracle WebLogic proxy plug-in	8 Aug	24 Aug	+16 days
CVE-2026-9198	IBM Langflow	21 Jul	4 Aug	+14 days
CVE-2026-8452	Citrix NetScaler	14 Aug	26 Aug	+12 days
CVE-2026-55040	Microsoft SharePoint	11 Aug	18 Aug	+7 days

Every one of those receipts is first-party: our own GitHub-harvesting cron finding public proof-of-concept code, extracting the target endpoints, and writing them to our index on a schedule, with timestamps we did not choose. Not an ingest of somebody else's research re-dated to look early. We have made that mistake before, corrected it publicly, and built a rule to stop repeating it.

What that meant in practice: on those seven, an organization running our free feed had detection content a median of sixteen days before CISA confirmed the vulnerability was being exploited in the wild. On Apache Tomcat, eighty-five days — nearly three months.

The seventeen, which is the more useful half

Seventeen blanks out of thirty is not a number a vendor puts on a slide. It is the number that makes the other seven mean anything, so here it is broken apart, because "seventeen misses" is not one thing.

Six of them are archaeology. CISA regularly catalogues old CVEs when fresh exploitation surfaces on them. Six of our blanks carry pre-2026 identifiers: CVE-2023-49105 (ownCloud), CVE-2022-0995 (Linux kernel), CVE-2021-23758 (Ajax.NET), CVE-2019-1068 (SQL Server), CVE-2015-5287 and CVE-2015-3246 (Red Hat).

Our exploit harvester hunts newly published proof-of-concept code. It is never going to hold a first-party receipt for a 2015 Red Hat libuser bug that CISA listed last week. That is not a failure of the machine, it is the shape of what the machine looks at — and counting those as misses would flatter us by muddying the number rather than explaining it.

Eleven are real gaps. Of the 23 CVEs in this window carrying a 2026 identifier, we held a receipt for 12 and had nothing on 11. Cisco Secure Firewall ASA. Windows Ancillary Function Driver. MLflow. TrueConf, twice. N-able N-central, twice. Microsoft's IKE service. Those are the ones worth working, and they are the reason this post exists in a form that is uncomfortable to publish.

Three we were behind on, and what that says

Three CVEs — Ray, Metabase, JetBrains TeamCity — we picked up two days after CISA listed them. Identical margin in all three cases.

That is not a coincidence, it is a cadence artifact. Our harvester runs on a schedule and CISA publishes on theirs; when a PoC lands in the gap, we arrive late by roughly the length of the gap. A two-day miss is a tuning problem, not a capability problem, and it is a fixable one.

Why publish the denominator at all

Because a lead statistic without one is marketing, and we would rather be useful than impressive.

"Median 16 days early" is true. It describes the 23% of cases where we were early. Quoted alone it implies a coverage level we do not have and would set an expectation that gets somebody hurt — the whole point of a feed is that a defender relies on it, and reliance built on a selected sample is worse than no feed at all.

The honest version has three parts and you need all three: we are meaningfully early on about a quarter of KEV listings, roughly a fifth of the catalog's traffic is old CVEs we structurally will not see, and on about a third of current CVEs we have nothing and you need somebody else.

That last clause is not a disclaimer. It is the operating instruction. Nobody should run one feed. Ours is free precisely so it can be one of several rather than a purchase you have to justify by pretending it is complete.

For the person reading this with no security team

If that is you — one admin, a rack of things you inherited, no budget line for threat intelligence — the practical read is short.

The feed is free and needs no contract. IP, domain and hash blocklists, OPNsense and Suricata formats, a Splunk-friendly output. Point a firewall at it. On roughly a quarter of the things CISA is about to tell you are being exploited, you will have had the indicators a couple of weeks early.

And on more than half you will not, which is why the same post that offers you the feed tells you its hit rate. Patch current, watch KEV, and treat any feed — ours included — as one input rather than a shield.

Sources

All thirty KEV additions between 28 July and 27 August 2026, from our own cisa_kev index, cross-referenced against receipts in our iocs index under source=exploit-harvester. Lead figures are the difference between our earliest record for the CVE and CISA's dateAdded.

A note on how this analysis nearly did not happen: the query that produces this table was returning 2026-02-10 as the most recent KEV addition — because dateAddedTs, the sortable field, was never populated by the sync that actually writes the index, so every recent entry sorted to the bottom. A sortable attribute nobody writes is worse than none at all: it answers, and the answer is wrong. Found and fixed today; verified by read-back before this table was built.

Capped at 95 percent: receipts are matched by CVE identifier, so a record referencing the vulnerability without that string would not be counted and our true lead count could be marginally higher. The 30 listings are what our KEV index held at time of writing. We have no telemetry on whether any reader actually blocked anything.

---

If you run this same check against your own tooling for the same thirty CVEs, I would genuinely like to see the result — including the blanks. Almost nobody publishes their denominator, and the field would be better if that changed. Rate this post below.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com