What was known, and when it was told
Four public records, joined by hand no longer: the fact of a vulnerability, the fact of a breach, the record of a leak, and the coverage of all three — and the interval between them.
Last reviewed September 4, 2026
- Four records, one measure. The interval between a fact and the coverage of it, which no aggregator keeps the pieces to compute.
- The lag runs -5 to 1777 days. Some flaws are told the day they are known; one took 1777 days to be mentioned at all.
- 589 breaches are ransomware, by the regulator's own classification — a confirmed floor, not a total.
- The sample is small and stated. 37 matched cases today; the method is proven, the volume is not yet.
The four records
Each answers a different question about the same event, and each is collected from public sources with its origin recorded. The value is not any one of them; it is the distance between them.
Why is the interval the product?
A single record answers a single question. That a vulnerability exists, that a company filed a breach notice, that a group posted a leak, that forty outlets wrote about something. Each is available on its own, and each on its own is close to worthless, because everybody has it.
What almost nobody has is the join. Keeping the fact of a flaw, the fact of a breach and the coverage of both in the same place, each with a reliable date, lets a question be asked that none of them answers alone: how long did it take? How many days between a vulnerability being known to be exploited and the first time the trade press named it? Between a company discovering a breach and telling anyone? Between a group claiming a victim and that victim confirming it to a regulator?
Those intervals are the whole of what this page reports, because they are the whole of what is scarce. An aggregator summarises the fourth record — the coverage — faster and at greater volume than this site ever will. It does not, and structurally cannot, tell you that the coverage arrived seventy days after the fact, because it never kept the fact.
The same instinct runs through the year-by-year pages in this archive, which measure attention rather than incidence. This page is that instinct with the missing half supplied: not just when something was written about, but when it was already known.
The economics underneath explain why the join is scarce and the summary is not. Restating a headline costs seconds and a model can do it for nothing, so the supply of summaries is effectively infinite and their price has collapsed to match. Reconciling four separately maintained registers — each with its own identifiers, its own update cadence, its own gaps — costs sustained upkeep that nobody undertakes casually, which keeps the supply of reconciliations near zero. Scarcity, not effort, is what a buyer pays for, and a reconciled interval is scarce precisely because assembling it is tedious, unglamorous and easy to get subtly wrong.
The lag, measured
Of the 6,677 vulnerabilities on file, 37 have so far been matched to press coverage that names them, with a date reliable enough to measure from. The distribution of that gap:
- shortest-5 days
- median3 days
- longest1777 days
- same day9 of 37
- told first4 — press before the catalogue
The longest gaps, which are where the intelligence sits, currently run:
- +1777dCVE-2018-20062 · ThinkPHP/noneCms — 1 article
- +1673dCVE-2017-9841 · PHPUnit/PHPUnit — 1 article
- +603dCVE-2024-55591 · Fortinet/FortiOS and FortiProxy · ransomware — 1 article
- +540dCVE-2025-24472 · Fortinet/FortiOS and FortiProxy · ransomware — 1 article
- +272dCVE-2025-20393 · Cisco/Multiple Products — 2 articles
- +236dCVE-2025-31125 · Vite/Vitejs — 1 article
The pattern already visible, on a handful of cases, is that severity buys speed. A flaw in a browser used by everybody is written about the day it is known; a flaw in an industrial device most readers have never heard of can sit for weeks with nobody mentioning it, exploited the whole time. That is a claim to hold loosely at this volume and to test as the sample grows.
Following one entry from end to end shows what the number compresses. A vulnerability in an obscure networking appliance is added to the exploited catalogue on a Tuesday, meaning somebody, somewhere, is already turning it against real targets. Nothing appears. No outlet carries it, because the vendor is unfamiliar, the product is niche and the story competes against louder ones. Weeks pass. Then a single trade title runs a short item, and the catalogue-to-coverage interval for that flaw closes at the far end of the range. During the whole of that silence the flaw was neither secret nor theoretical: it was catalogued, public and in use. The interval measures how long a known, exploited weakness stayed beneath the notice of the outlets a defender reads.
Aggregated across enough cases, that measure stops being an anecdote about one appliance and becomes a property of the coverage itself: which classes of product it tracks promptly, which it reaches late, and which it never reaches while they are being exploited. That is a statement about the press, not about the flaws, and it is one only a record holding both halves can make.
Why is only one date trusted?
The lag is measured from a single date: the day a vulnerability entered the public exploited-vulnerabilities catalogue. Every other candidate date was considered and set aside, and it is worth saying why, because the discarded ones are the ones a careless version of this page would have used.
A vendor advisory carries a date, but the one exposed in its feed is the date of the last revision, not of first publication. Measuring from it produced negative gaps — a flaw apparently disclosed after it was already known to be exploited — which is the signature of a date that means something other than what it claims. So advisory dates enrich the record with the vendor's own description of a flaw, and are never used for timing.
Every matched item therefore carries a flag: its lag is either measured, from the reliable date, or marked unknown. A count of measured cases and a count of unknowns are two different numbers, and this page never adds them together to look larger.
The honest disclosure date — when a vendor first published — would need a heavier source than a feed, and getting it is a known next step rather than a solved one. Until then the catalogue date is the floor of what can be measured cleanly.
Breaches, confirmed by a regulator
Alongside the vulnerabilities sit 2,122 breach notifications — public records filed by companies with state regulators when they lose residents' data. They record the fact of a breach and never its contents: the company, the dates, how many people, and often the cause. Of them, 589 are attributed to ransomware by the regulator itself.
The most recently filed, by notification date:
- 2026-09-09Quatrro Business Support Services, Inc. · ransomware10,008
- 2026-09-08Hibbett Retail, Inc.510
- 2026-09-04Catalyst Brands LLC4,015
- 2026-09-04Bimbo Bakeries USA786
- 2026-09-04LHC Group, Inc.6,602
- 2026-08-28AvtechTyee, Inc. · ransomware662
- 2026-08-28RB American Group LLC · ransomware974
- 2026-08-24Pan American Group LLC · ransomware12,309
The ransomware count is a floor, not a total, and the reason is instructive. One state in this record classifies each breach by attack type; another files them with no cause at all. A ransomware incident reported to the second state is real and uncounted here. The figure is therefore a confirmed minimum — every one of the 589 is a regulator saying ransomware, and an unknown number more are hidden in the vaguer filings.
These filings exist because the law compels them, and that origin shapes what they can and cannot tell you. A company files because a statute in the affected state requires notice above some threshold of residents, so the record over-represents the states with strict rules and under-represents incidents just below a threshold or touching only residents of states that demand less. The affected-count is the number the company was willing to certify to a regulator, not an investigator's estimate, so it errs toward the conservative. None of this makes the figures wrong; it makes them legal artefacts with a shape, and reading them as a neutral census of harm would import that shape unnoticed.
What does the leak record add, and refuse?
The fourth record is a log of leak-site activity: which groups claim which victims, and the domains they use to post. It is kept because that infrastructure is itself intelligence — the domains rotate, and knowing which have already been used is reusable.
It closes a loop the other records leave open. A group claims a victim on its wall; weeks later that victim may file a breach notice with a regulator classifying the cause as ransomware. Holding both lets a single sentence be written with both halves attested: the claim, and the confirmation, and the days between. That join is the part no aggregator has, because no aggregator keeps the claim and the filing in the same place.
What the record does not do is fixed and does not move. It does not download the leaked data, does not follow the link to the stolen files, and does not publish that link. The harm of a breach falls on people who never chose to be in it, and every copy of the dump adds to it. The intelligence is the pattern — who, when, how long — not a route to the material, and the deep links that exist are held internally, disabled, as an audit trail and nothing else.
How small is small, really?
Every figure on this page is a floor that has probably risen since the last build, because collection runs daily and the records only grow. But honesty about the present size matters more than the direction of travel.
The lag rests on 37 matched vulnerabilities. That is enough to show the method works and to surface individual cases worth knowing; it is not enough to state a reliable distribution, and a median across 37 cases is quoted as an observation, not a law. The breach and vulnerability counts are already in the thousands and support proportions; the matched-lag figure is the young one, and it is the one held most carefully.
The distinction the whole site runs on applies here too. A thin sample is not a weak method — it is a young one. What would make these figures untrustworthy is not their size but a claim larger than they support, and the page is built to make that claim impossible: the counts are computed, the sample sizes are shown beside the numbers, and the one date that cannot be trusted for timing is never used for it.
How four registers become one measurement
Joining separate registers is fiddly plumbing, and naming the steps shows why the result is not something a summary of the news could ever produce:
- Normalisation. Every register spells its dates, its vendor names and its severity ratings differently; each is coerced into one canonical shape before anything is compared.
- Identifier matching. A vulnerability is joined to its coverage by the CVE label, an exact key, rather than by fuzzy product names that would breed false pairings.
- Deduplication. A wire story republished across a dozen outlets, or a breach filed in two states, is collapsed to a single underlying event so volume never masquerades as significance.
- Date arbitration. Where registers disagree about chronology, the trustworthy timestamp is chosen and the unreliable one — a revision masquerading as a disclosure — is quarantined.
- Provenance stamping.Each surviving figure keeps a pointer to the register and row it descended from, so a sceptic can retrace the arithmetic to its origin.
The steps are unglamorous individually and expensive collectively, and that expense is the moat. Anybody can paraphrase a bulletin; sustaining the reconciliation above, day after day, across registers that mutate without warning, is the part few will bother to maintain and none can fake with a plausible-looking dashboard.
The registers are named plainly, because provenance withholds nothing. Exploited vulnerabilities come from the Cybersecurity and Infrastructure Security Agency catalogue; vendor advisories from Microsoft; breach filings from the Washington attorney general and the Delaware Department of Justice, delivered through their open Socrata endpoints; coverage from syndicated feeds in the RSS and Atom formats, fetched conditionally against an entity tag so an unchanged source is never re-downloaded. Each identifier follows the Common Vulnerabilities and Exposures scheme, a shared vocabulary that lets a Redmond advisory and a Washington filing meet without a translator. Where a jurisdiction differs — Delaware omitting an attack classification that Washington records — the divergence is preserved, not averaged away into a tidier but falser uniformity.
Freshness is enforced mechanically rather than trusted. Each source is polled on a fixed daily cadence; a catalogue answering that nothing changed is skipped without penalty; duplicate identifiers already seen are discarded before writing. The upshot is a ledger that accretes steadily and never double-counts, whose age is always knowable because every row carries the timestamp of its own arrival. The polling is courteous by construction: a declared crawler string, a throttled request rhythm, and honoured exclusion rules, so the harvesting neither burdens a publisher nor hides from one. Two publishers who granted written permission are honoured through a signed, dated allowance rather than a blanket exception, keeping even the exceptions auditable.
Who reads a number like this?
A defender triaging a queue of advisories has a scarce budget of attention and a remediation window measured in hours. The exploited-vulnerabilities catalogue already tells them what to patch; what it does not tell them is how visible each weakness is about to become. A flaw the trade press has ignored for a month is one whose exposure a board has not yet heard about, which changes the politics of prioritising it — the engineer arguing for an emergency patch cycle wins that argument more easily once the headline lands, and loses it while the silence holds.
An underwriter pricing cyber cover reads the same interval differently. To them the lag is a proxy for how long an insured organisation might operate a known-exploited weakness in the dark, unprompted by any external signal, before the noise of coverage forces a response. A supplier-risk team reads it as a warning about their vendors: the appliances that sit longest between exploitation and coverage are, disproportionately, the embedded and industrial devices nobody markets and everybody deploys, threaded through supply chains where a single unpatched box exposes many downstream customers at once.
None of those readers is served by another summary of the week. Each is served by a durable, dated reconciliation they can query against their own portfolio, their own vendors, their own patch calendar. That is the shape of the paying audience, and it is why the interval is priced as an instrument rather than as content.
What provenance buys
Every figure here carries its lineage: the register it came from, the date that register stamped, and the flag saying whether that date can bear the weight of a measurement. That bookkeeping is invisible in the headline number and decisive underneath it. A reconciliation nobody can audit is a rumour with decimal places; one whose every input can be traced back to a named public register is a claim a sceptic can dismantle and rebuild, and the ability to dismantle it is exactly what makes it worth trusting.
The discipline shows most in what gets withheld. When two dates disagree about which came first, the contradiction is surfaced rather than smoothed; when a register offers a tempting field whose meaning is a revision timestamp rather than a disclosure, that field is quarantined from the arithmetic and labelled. The cost of that honesty is a smaller headline count — fewer matches, narrower claims — and the return on it is that the counts survive contact with somebody who checks. In a market where fabricated dashboards are cheap and abundant, a defensible number is the differentiated product, and defensibility is a property of provenance, not of presentation.
What this is, and is not
It is a measure of intervals. Between a fact appearing in one public record and its coverage appearing in another, computed from the records at build time.
It is not a threat feed. It does not tell you what to patch today; the exploited-vulnerabilities catalogue it draws on does that better, and is linked from the data. This measures the reporting around such facts, not the facts as an alert.
It is not complete. Two states supply the breach record, not fifty; one catalogue supplies the exploited vulnerabilities; the press record is the publications this site follows and no others. Every one of those boundaries is stated where the figure that depends on it appears.
It is not the paid product. This page demonstrates the method on public records. The deliverable that joins the leak log to the breach filings in full is a separate, private document, and this page is the evidence that the machine behind it works.
Common questions
What does this page measure?
The gap between when something was known and when it was written about. It joins four records this site keeps — press coverage, exploited-vulnerability catalogues, vendor advisories and state breach notifications — and reports the interval between a fact appearing in one and coverage of it appearing in another. All 6,677 vulnerabilities and 2,122 breach notifications behind it are counted from the records, not recalled.
Why is the sample so small?
Because forward collection began recently. The lag figure rests on 37 matched vulnerabilities today, which is enough for examples and not yet for statistics — a median of 3 days across 37 cases is an observation, not a distribution. It grows every day the collection runs, and the page says so rather than dressing a handful of cases as a trend.
How is the lag computed?
From the date a vulnerability entered the CISA exploited-vulnerabilities catalogue to the date of the earliest press coverage mentioning its identifier. Only that catalogue date is used, because it is reliable; a vendor advisory's feed date is a revision date, not a disclosure date, so it is never used for timing. Every matched item carries a flag saying whether its lag is measured or unknown.
Does a long lag mean the press was slow?
No, and the distinction matters. A long gap can mean a flaw was not newsworthy until something made it so — a large victim, a working exploit, a vendor statement. The figure measures the interval and does not interpret it. Interpretation is editorial and carries its caveats in the text.
What are the breach notifications?
Public records filed by companies with state regulators when they lose residents' data. This page draws on 2,122 of them, from 2 states, of which 589 are attributed by the regulator to ransomware. They record the fact of a breach — company, dates, how many affected — never the stolen data itself.
Where does the ransomware figure come from?
From the regulators, not from us. A breach counts as ransomware here only when the filing state classified it that way. 589 of the 2,122 notifications carry that classification. It is a floor, not a total: many ransomware incidents are filed under a vaguer cause.
Can I get the underlying data?
The records behind this page are available as a dataset, with their documented limits attached. What is not published is anything that would point a reader at stolen data: the intelligence is the pattern — who, when, how long — not a route to the leak.
How current is it?
The figures are as at the last build. Collection runs daily and the records grow between builds, so a count here is a floor that has probably risen. The coverage record currently holds 2,215 entries from 37 publications.
Why does this exist when aggregators already summarise the news?
Because summarising the news is now free and consequently worth little, while joining separate public records with provenance is not something an aggregator does. No competitor keeps the fact of a vulnerability, the fact of a breach and the coverage of both in a way that lets the interval between them be measured.
What can it not answer?
Anything needing the content of a breach, the cost of an incident, or whether a control worked. The records hold what regulators and catalogues publish and what the trade press wrote, and every page here states where that runs out rather than guessing past it.
Is the ransomware attribution reliable?
It is as reliable as the regulator's classification, which is the honest limit. Washington records an attack type per breach; Delaware does not, so a Delaware ransomware case may be filed with no cause and go uncounted here. The figure is therefore a confirmed minimum, and the page treats it as one.
Does the site follow leak sites?
It records the fact that a leak was posted and the domains used to post it, as infrastructure intelligence. It does not download the leaked data or link to it. That line is deliberate and does not move: the harm of a breach falls on people who did not choose to be in it, and copying the dump adds to it.
The data behind this page
Everything above is computed at build time from records collected daily, the same way the figures on the method page are. The coverage record holds 2,215 entries from 37 publications; the vulnerability records hold 6,677; the breach record, 2,122.
The dataset is available with its documented limits attached — the pricing page sets out how, and the research address is where to ask. A wrong figure means the records or the computation is wrong, and both are worth hearing about: [email protected].