The vulnerability that gets you is eight months old
Security advice has a bias towards the new. The advisory lands, the vendor publishes, the news picks it up, and everyone patches the thing that was announced this week. It feels like the right instinct, because an attack you have not heard of yet is the one that worries you.
The record says otherwise. We measured the gap between a vulnerability being published and being confirmed as used in a real attack, across 1,732 flaws in CISA's Known Exploited Vulnerabilities catalogue.
The median gap is 242 days. The typical vulnerability that gets used against someone had been sitting in public, documented and patchable, for about eight months first.
The distribution
| Time from publication to confirmed exploitation | Flaws | Share |
|---|---|---|
| Catalogued before the CVE was published | 72 | 4.2% |
| Same day | 159 | 9.2% |
| 1 to 7 days | 201 | 11.6% |
| 8 to 30 days | 130 | 7.5% |
| 31 to 365 days | 390 | 22.5% |
| More than a year | 780 | 45.0% |
Read the top and the bottom together, because they say opposite things and both are true.
At the top, 13.3% were exploited on the day of publication or before it. That is the scenario everyone plans for: the emergency patch, the out-of-hours call. It is real, and it is about one in eight.
At the bottom, 45.0% were confirmed as exploited more than a year after publication. A quarter took more than 1,348 days, over three and a half years. One in twenty took more than 3,490 days, close to a decade. The oldest in the record was catalogued 7,191 days after publication, which is 19.7 years.
That long tail is not an oddity in the data. It is nearly half of everything in it.
What that means in practice
If your patching effort is organised around what is new, you are covering the first two rows of that table well and the last row barely at all. And the last row is where most of the volume is.
The vulnerabilities being used against businesses are, more often than not, ones that were published while you were busy with something else, triaged as not urgent because nothing was exploiting them, and then quietly filed. They were correctly deprioritised at the time. The information that would have changed the decision did not exist yet, and arrived on average eight months later, when nobody was looking at that list any more.
This is a different problem from patching speed. You can be fast at patching new things and still be exposed, because the exposure is in the backlog rather than the inbox.
The record sometimes lags the attack
There is one more group worth naming. 72 vulnerabilities were catalogued as exploited before the CVE describing them was published at all.
These are genuine, not artefacts. They are mostly in-the-wild browser and operating system flaws where the authorities acted on active exploitation ahead of the formal record. Two Firefox flaws, CVE-2022-26485 and CVE-2022-26486, entered the catalogue 290 days before publication. CVE-2022-1096 in Chrome did so by 117 days.
For those, the public vulnerability record was not an early warning. It was a record of something that had already happened. That inverts what most people assume a vulnerability database is for, and it is worth knowing that the assumption fails in a small but real fraction of cases.
The 72 are a floor rather than a count. A flaw only shows up in this group if it was catalogued as exploited and the formal record came late enough for the gap to be visible. The true rate of exploitation-before-publication is higher, and it is not measurable from this data.
What to do with this
- Do not close the list when the news moves on. A vulnerability you triaged as low priority six months ago is exactly the profile of the ones that get used. Revisit rather than archive.
- Re-check old vulnerabilities against exploitation data, not just severity. The severity score does not change when a flaw starts being exploited in the wild. Exploitation catalogues do, and they are free to check.
- Treat "nothing is exploiting this yet" as a statement with a shelf life. It was true when you assessed it. The median says it stays true for about eight months.
- Ask whoever handles your patching how old the oldest unpatched item is. If nobody knows, that is the answer. The backlog is where the risk sits, not the inbox.
- Accept that a small share will always be same-day. One in eight is unavoidable, which is an argument for being able to patch quickly, not for watching only the new.
How Steelwise can help
Working out what is actually unpatched in your business, how old it is, and which of it matters, is the sort of question a security review answers directly. Get in touch.
About the data. Figures come from our analysis of public vulnerability records sourced via StackFlag, which is a Steelwise product, queried on 4 October 2026. The underlying data is public: the National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.02). Intervals are measured between the publication date and the date CISA added the flaw to its catalogue, across 1,732 of the 1,733 flaws catalogued between November 2021 and October 2026. One, CVE-2022-22965, was excluded because its stored publication date was wrong. That error came from a known fault in how StackFlag handles dates from different sources. It produced one impossible interval, which we caught. An error that produced a plausible interval would not be visible, so treat the percentiles as approximate to within a few days. Exploitation is measured against CISA's catalogue, which records confirmed exploitation rather than all of it, so the underlying population is itself a floor.
If you spot an error in this filing, tell us and we will correct it and note the change.
Further reading
Correction
4 October 2026, 16:06 BST. This filing was first published on 4 August 2026, under the title "The vulnerability that gets you is nine months old". We re-ran the analysis after repairing the dataset behind it, and the figures have changed.
The median gap between publication and confirmed exploitation is 242 days, not 272, so the typical exploited flaw is about eight months old, not nine. The share taking more than a year is 45.0%, not 46.9%. The number catalogued before publication is 72, not 62. The analysis now covers 1,732 flaws, up from 1,656.
The original also excluded 101 records whose dates could not be established, and gave a range the true figures might fall in. Those records turned out to be empty leftovers in our own store, not entries in CISA's catalogue, so that caveat no longer applies and has been removed. The conclusion is unchanged: nearly half of exploited flaws are more than a year old when exploitation is confirmed.
← All filings