The vulnerability that gets you is nine 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,656 flaws in CISA's Known Exploited Vulnerabilities catalogue.
The median gap is 272 days. The typical vulnerability that gets used against someone had been sitting in public, documented and patchable, for about nine months first.
The distribution
| Time from publication to confirmed exploitation | Flaws | Share |
|---|---|---|
| Catalogued before the CVE was published | 62 | 3.7% |
| Same day | 151 | 9.1% |
| 1 to 7 days | 175 | 10.6% |
| 8 to 30 days | 117 | 7.1% |
| 31 to 365 days | 375 | 22.6% |
| More than a year | 776 | 46.9% |
Read the top and the bottom together, because they say opposite things and both are true.
At the top, 12.9% 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 one in eight.
At the bottom, 46.9% were confirmed as exploited more than a year after publication. A quarter took more than 1,403 days, nearly four years. One in twenty took more than 3,547 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 nine 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. 62 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 62 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 nine 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. The underlying data is public: the National Vulnerability Database and CISA's Known Exploited Vulnerabilities catalogue. Intervals are measured between the NVD publication date and the date CISA added the flaw to its catalogue, across 1,656 records catalogued between November 2021 and July 2026. A further 101 records were excluded because their publication dates could not be reliably established, and one because its date came from the wrong source. Including the excluded records would raise the same-day share from 9.1% to 14.3% and lower the median from 272 to 210 days, so treat the same-day figure as a lower bound and the median as an upper one. 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.