N-Day to N-Hour: Why Patching Faster Stopped Being Enough

Look at the pattern from this single week. A WordPress flaw got a public proof-of-concept and mass exploitation followed in about two days. A SharePoint bug from Patch Tuesday went from public PoC to attackers stealing machine keys. A Palo Alto VPN authentication bypass got picked up by a ransomware crew for initial access. None of these were secret zero-days. They were patched vulnerabilities, disclosed, with fixes available, being exploited faster than most organizations could apply the fix.

That is the shift worth naming. N-day, the known and patched vulnerability, used to give you a comfortable buffer to deploy. That buffer has collapsed. The Zero Day Clock puts 2026’s average time from disclosure to exploitation at under 24 hours, down from about 53 days in 2024. N-day is becoming N-hour, and the strategy most programs still run was built for the old clock.

The Patch Is a Map for the Attacker

Here is the mechanic that makes this inevitable, and it is worth sitting with because it is not going away.

When a vendor ships a security fix, the fix is a diff. The difference between the old code and the new code points at exactly what was broken, in exactly which function, with exactly which input. To a defender that diff is a patch to deploy. To an attacker it is a map with an X on it. Reverse the change, understand the flaw it closed, and you have the shape of the exploit. This has always been true, which is why serious attackers have long watched patch releases as a source of targets.

What changed is the speed of the reversal. Turning a patch diff into a working exploit used to take a skilled human days or weeks. Now it takes a model minutes. Anthropic’s own researchers turned 18 Firefox patches into 8 working exploits, and their first one landed under an hour after Mozilla shipped the fix. Against the Windows kernel, the same approach built proof-of-concept crashes for 18 of 21 bugs, the fastest in 31 minutes. This is the same capability class that, as we saw this week, broke out of a lab and hacked a third party on its own. Pointed at a patch diff, it is an exploit factory that runs at machine speed.

So the artifact meant to protect you is the same artifact that arms the attacker, and the attacker now weaponizes it faster than you can roll it out.

The Math Does Not Work Anymore

Put the two numbers next to each other and the problem is obvious.

Time from disclosure to a working exploit: under 24 hours, trending toward single-digit hours. Time for a real organization to test and deploy a patch across its estate: Verizon’s 2026 Data Breach Investigations Report puts the median at 43 days, and finds that only about 26% of vulnerabilities ever get fully patched at all.

Those two clocks are not close. One runs in hours, the other in weeks, and the gap between them is the window the attacker lives in. You can pour resources into “patch faster,” shave your median from 43 days to 20, run an emergency change process, and you have closed almost none of the gap, because the exploit was ready the afternoon the patch shipped. The uncomfortable truth is that patch speed, as the centerpiece of a vulnerability program, is a race you lost before you started running.

I want to be careful here, because this is easy to misread. This is not an argument to stop patching. Patching is still how vulnerabilities actually get closed, and a 43-day median with a quarter of bugs never fixed is its own failure that deserves fixing. The point is narrower and more important: patch speed can no longer be the whole strategy, because even a good patch program cannot move in the hours you now have.

Stop Asking “Patch or Not.” Start Asking “Is It Reachable, and Does My Control Hold.”

If you cannot win on speed, you win on evidence. The programs that handle this well have quietly stopped treating a vulnerability score as a work order and started treating it as a question to be answered with proof.

The question is not “how severe is this CVE.” It is two questions. Can an attacker actually reach this thing in my environment? And if they run the exploit, does one of my controls actually stop it? A critical-rated flaw on an asset no one can route to is a lower priority than a medium-rated flaw sitting on your internet edge, and a scanner that only reads version numbers cannot tell you which is which. Proof can.

Prove reachability on the assets you can safely test. For the portion of your estate you can exercise without breaking it, roughly the 10 to 15% that is genuinely reachable and testable, run the actual exploitation and see what happens. Not a scan that infers risk from a version string, but a real attempt against a safe target that tells you whether the path exists. Most of what a scanner flags critical turns out to be unreachable, unexploitable in your configuration, or already blocked by something you forgot you had. Finding that out converts a fire drill into a filed ticket.

Validate the control chain on the assets you cannot test. For the other 85 to 90%, the production systems you cannot safely detonate an exploit against, decompose the attack into its steps and prove each step breaks against your controls. An exploit is a chain: reach the service, trigger the flaw, execute code, escalate, move. You do not have to run the whole chain on a live system to know you are covered. You have to show that at least one link in it hits a control that holds. If the initial access technique is blocked, or the post-exploitation move is caught, the unpatched flaw is contained even before you touch it.

Watch for control drift continuously. The control that broke the attack chain last month is only protecting you if it is still configured the way you think it is. Rules get changed, exceptions get added during a migration and never removed, an agent stops reporting. Continuously simulating the techniques you rely on catching, against your own stack, is how you learn a control has drifted before an attacker learns it for you. This is the same reasoning that runs under the layered model in our ransomware prevention framework: assume the flaw will be there and the exploit will come, and make sure the blast is contained by something other than the patch.

Shrink what is reachable in the first place. The cheapest exposure to defend is the one that is not exposed. Every service you take off the public internet, every management interface you move behind the VPN, every unused feature you disable is a vulnerability that no longer matters the moment its class of bug drops. This is the daily work of external attack surface management, and in an N-hour world it pays off more than ever, because the fastest patch is the one you never have to apply.

Patch, Mitigate, Monitor, or Accept

The output of all of this is a better decision than “critical, so drop everything.” For each real exposure you now have four honest options, chosen on evidence rather than a number.

Patch it, if you can do so inside the window that matters, which for a reachable internet-facing flaw now means today, not this sprint. Mitigate it, with a virtual patch at the WAF, a firewall rule, a disabled feature, or a config change that breaks the exploit while the real fix works its way through change control. Monitor it, if a control already contains the attack and you want eyes on the path in case that control drifts. Or accept it, explicitly and in writing, if it genuinely is not reachable and the cost of touching it exceeds the risk.

Three of those four are things you can do in the hours you actually have. Only one of them is the patch, and the whole point is that you can no longer count on the patch arriving in time.

The Clock Is Not Going Back

The uncomfortable part of this is that it gets worse, not better. The capability that turns a patch into an exploit in 31 minutes is improving on the same curve as everything else in AI, and the tools to do it are getting cheaper and more available. The gap between disclosure and exploitation is not going to widen back out to 53 days. It is going to keep closing.

That is not a counsel of despair, because the answer does not depend on out-racing the attacker to the patch. It depends on knowing, before the next critical drops, which of your exposures are actually reachable, which of your controls actually hold, and which unpatched flaw is already contained by something other than luck. An organization that can answer those three questions is not scrambling when the PoC lands. It already knows which of its systems are in the blast path and which are not, and it spends the precious hours after disclosure on the handful that matter instead of all of them at once.

Patch faster, yes. And build the program that does not depend on you winning a race the attacker rigged the moment the fix shipped.

If you want to know which of your exposures an attacker could actually reach and exploit right now, rather than which ones a scanner rated critical, that is the work we do. Start with our free Human Attack Surface Score, or contact Grab The Axe and we will find the reachable ones the way an adversary would.

Director of Information Security

Chris Armour

The Breaker & Builder.

Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.

View Author Page →