Zero-Day Exploits Are Getting Faster — Your Patch Window Is Now Hours, Not Days

Last Thursday at around 2:15 AM, my phone buzzed with an alert from our vulnerability scanner. A new critical CVE had dropped — something in a web framework we use on three client sites. I rolled over, squinted at the screen, and thought: "I will deal with this in the morning."

By 8 AM, one of those sites had already been probed. Not breached, thankfully — our WAF caught it. But the exploit code? It was public within six hours of the disclosure. Six hours. I was still sleeping.

Welcome to 2026, where the time between a vulnerability being disclosed and someone weaponizing it has collapsed to the point where "patch Tuesday" might as well be "pray Tuesday."

The Numbers Are Getting Scary

I have been tracking time-to-exploit data as a hobby (yes, I am that fun at parties) since about 2021. Here is what the trend looks like:

• 2021: Average time from CVE disclosure to first exploit in the wild — about 42 days
• 2023: Down to 15 days
• 2024: Roughly 5-7 days for critical vulnerabilities
• 2025: 24-72 hours for the really nasty ones
• 2026 so far: Several high-profile CVEs were exploited within hours of disclosure

A report published this week by a major vulnerability management firm projects that by 2028, time-to-exploit for critical vulnerabilities could be measured in minutes, not hours. Minutes. Let that sink in while you think about your current patch management workflow.

My colleague Rachel — she runs security for a mid-size healthcare company — put it perfectly: "We used to have a weekend. Now we do not even have a lunch break."

Why Is This Happening?

Three things are converging at once, and none of them are good for defenders.

1. AI-Assisted Exploit Development

This is the one nobody wants to talk about at security conferences, but everyone is thinking about. Large language models can now analyze a CVE description, identify the vulnerable code path, and generate a working proof-of-concept exploit in minutes. Not every time. Not perfectly. But often enough that the barrier to entry for exploit development has dropped through the floor.

I watched a security researcher demonstrate this at a private event in January. He took a freshly disclosed CVE in a popular CMS plugin, fed the advisory text and the diff into an AI model, and had a working exploit within 40 minutes. The old-school way? That would have taken a skilled researcher several hours to several days, depending on complexity.

"The asymmetry is broken," he told me afterward, looking genuinely worried. "Defense still takes the same amount of time. Offense just got ten times faster."

2. Automated Scanning at Scale

Within hours of any major CVE disclosure, automated scanners are sweeping the entire IPv4 space looking for vulnerable targets. Tools like Shodan, Censys, and ZoomEye — originally built for legitimate security research — make it trivial to find every exposed instance of a vulnerable service. And the attackers have their own private scanning infrastructure that is even faster.

When Log4Shell dropped in December 2021, mass scanning began within hours. That was considered shockingly fast at the time. Now? It is the baseline expectation. If you are running a vulnerable service on a public IP, you should assume someone knows about it within an hour of a CVE dropping.

3. The Expanding Attack Surface

This is the one that keeps me up at night more than the others. Most organizations have no idea how large their actual attack surface is. Shadow IT, forgotten test servers, that staging environment someone spun up three years ago and never decommissioned, the API endpoint that marketing's agency set up and nobody documented.

I did an attack surface assessment for a 200-person company last year. They thought they had about 15 internet-facing services. The actual count? 47. Forty-seven attack surfaces, and their security team was only monitoring about a third of them.

A security team leader I spoke with put it this way: "When a zero-day drops, I need to patch 47 things. But my asset inventory says 15. So 32 of them sit there, unpatched, until someone finds them — either us or an attacker. Usually the attacker wins that race."

What Actually Works (And What Does Not)

I have spent the last year testing different approaches to rapid vulnerability response. Here is what I have found actually makes a difference.

What Works: Asset Inventory (The Boring Answer)

You cannot patch what you do not know exists. I know this sounds like a security 101 platitude, but I am consistently amazed by how many organizations — including ones with dedicated security teams and six-figure tool budgets — do not have a complete inventory of their internet-facing assets.

Start here. Run continuous external asset discovery. There are free tools that do this (ProjectDiscovery's suite is excellent), and paid platforms if you want something more polished. Do it weekly at minimum. The goal is simple: no surprises when the next CVE drops.

What Works: Pre-Staged Patching Playbooks

When a critical zero-day drops at 2 AM, you do not want your incident response to start with "okay, who owns this server again?" Every critical service should have a pre-written playbook that answers: who is responsible, what is the patch process, what is the rollback plan, who needs to be notified.

I started doing this for my clients last year. The first time it saved us was a WordPress plugin vulnerability in April. The CVE dropped on a Saturday morning. By Saturday afternoon, all affected sites were patched. The playbook took 20 minutes to execute. Without it? Best case, Monday morning. Worst case, "I think Dave handles that server but he is on vacation."

What Works: Reducing the Surface Aggressively

Every service you remove from the internet is one less thing to emergency-patch. I am a broken record about this with my clients: if it does not need to be publicly accessible, put it behind a VPN or zero-trust proxy. Your admin panel does not need to face the internet. Your staging server definitely does not. That internal API endpoint? Lock it down.

One client reduced their internet-facing services from 31 to 12 in a single quarter. When the next critical CVE dropped, they had 12 things to check instead of 31. That is not a minor difference — it is the difference between responding in an hour and responding in half a day.

What Does NOT Work: Relying on CVSS Scores Alone

CVSS scores are useful but they are not actionable intelligence. A CVSS 9.8 in a service you run on an air-gapped network is less urgent than a CVSS 7.5 in your public-facing login page. Context matters more than numbers.

I have seen teams spend their entire patch window fixing a CVSS 10.0 in an internal-only service while a CVSS 7.8 in their externally-exposed API sat unpatched. Guess which one got exploited?

What Does NOT Work: Annual Penetration Tests

If your security validation happens once a year, you are checking the locks on your house once a year while burglars are testing them daily. Annual pentests were fine in 2015. They are dangerously insufficient in 2026.

At minimum, do continuous automated security validation. Tools exist. They are not as good as a skilled human pentester, but they catch the low-hanging fruit that attackers are automating anyway. Think of it as brushing your teeth daily versus going to the dentist once a year — you need both, but if you only do one, the daily one matters more.

My Personal Zero-Day Response Protocol

For what it is worth, here is what I actually do when a critical CVE drops. This is not perfect, but it has kept my clients safe through every major vulnerability since I started using it in mid-2025:

1. Within 15 minutes: Automated alert fires. I check if we are affected (pre-built asset inventory makes this a 2-minute lookup, not a 2-hour scramble).
2. Within 1 hour: If affected, implement temporary mitigation — WAF rules, IP restrictions, feature disable. Anything to buy time.
3. Within 4 hours: Apply the actual patch to production. Test in staging first only if the vulnerability is not yet being actively exploited. If it is being exploited in the wild, patch first, test second. I know that sounds reckless. It is less reckless than being breached.
4. Within 24 hours: Full validation. Confirm the patch worked. Check logs for any signs of pre-patch exploitation. Update the playbook with lessons learned.

Is it stressful? Absolutely. I have aged approximately fifteen years since 2023. But it works. And in a world where exploit development takes hours instead of weeks, "stressful but effective" beats "comfortable but compromised."

What Is Coming Next

I do not want to be alarmist, but I also do not want to sugarcoat this. The trend line is clear: time-to-exploit is approaching zero for critical vulnerabilities. Within the next 2-3 years, we will likely see AI models that can generate working exploits within minutes of a CVE disclosure, not hours.

The security industry is going to have to fundamentally rethink patch management. The old model of "scan weekly, patch monthly, pentest yearly" is already obsolete. The new model has to be "know everything, mitigate instantly, patch within hours, validate continuously."

Or, as Rachel told me over coffee last week: "Maybe we should just have fewer things on the internet." Honestly? That might be the most practical advice of all.

If you run internet-facing services and your patch SLA is measured in days or weeks, it is time to have an honest conversation about whether that timeline matches the current threat environment. The attackers have already had that conversation. They decided hours was fast enough.