The exploit window has collapsed: when a CVE drops, you have hours — not weeks

When a vulnerability is disclosed today, the question is no longer “when will we get around to patching it?” It’s “are we already too late?”

For most of the last two decades, defenders had a buffer. A CVE would be published, a patch would follow, and organisations had days — often weeks — before attackers built a reliable exploit and went looking for unpatched systems. That buffer is the quiet assumption underneath almost every patch-management policy, every “we patch monthly” reassurance given to a board, every risk register that rates an unpatched system as “we’ll get to it.”

That assumption is now wrong, and the gap is closing fast.

The numbers are moving in the wrong direction — on both axes

Two things are happening at once, and together they compound.

First, the volume of disclosed vulnerabilities keeps hitting record highs. The number of CVEs published each year has climbed past 40,000 — more than 100 new disclosed vulnerabilities every single day, weekends included. No security team on earth can meaningfully triage, test and remediate at that rate without ruthless prioritisation, and most organisations have no defensible basis for deciding what to fix first.

Second, the time-to-exploit — the window between a vulnerability becoming known and it being actively weaponised — has collapsed. Threat-intelligence research now routinely measures that window in days, sometimes hours. A growing share of serious vulnerabilities are exploited as zero-days: weaponised in the wild before a patch exists at all. For those, your patch cadence is irrelevant. There was nothing to patch when the attack started.

The defender’s buffer hasn’t shrunk. For an increasing class of attacks, it has disappeared entirely.

Why this is accelerating now

The accelerant is automation — and increasingly, AI. The work that used to gate an exploit campaign (reading the disclosure, understanding the bug, writing a reliable trigger, scanning the internet for exposed targets) was slow because it took skilled human time. Each of those steps is now partly or fully automated. Mass internet scanning identifies every exposed instance within hours of a disclosure. Exploit-generation tooling shortens the path from “interesting bug” to “working weapon.” The economics have flipped: it is now cheaper and faster to attack at scale than to defend by hand.

This is the part most boards haven’t internalised. Cyber risk used to be governed on human timescales. It is now governed on machine timescales — and a quarterly patch review, however diligent, runs on the wrong clock.

What this means for how you govern risk

If exploitation now outpaces patching for a meaningful slice of your exposure, then “are we patched?” is the wrong governing question. The right ones are harder:

• What is actually exposed? Not what the asset register says — what an attacker scanning your perimeter would actually find today, including the systems nobody remembers standing up.
• If we can’t patch in time, can we contain? Segmentation, least privilege and detection are what carry you through the window when no patch exists. A zero-day you can’t reach is far less dangerous than one sitting flat on a flat network.
• Do we know first — or do we find out from the attacker? The difference between a contained incident and a board-level crisis is almost always how quickly you detected it.
• What is our prioritisation actually based on? “Critical/High/Medium” from a scanner is not a risk decision. Exploitability, exposure and blast radius are.

None of these can be answered honestly from inside the patch queue. They require stepping back and looking at the whole environment the way an attacker would — which is precisely what most organisations never do until after a breach forces them to.

The honest position

You cannot out-patch a threat landscape that now moves faster than your remediation cycle. What you can do is know — with evidence, not optimism — exactly where you are exposed, what an attacker could reach, what to fix first, and what would contain the damage when (not if) something lands inside the window.

That is what an independent, senior-led security audit is for. It is the difference between a board that is governing cyber risk and a board that is hoping.