Zero-Day Clock Says Exploit Window Is Now 24 Hours

Anyone who has ever sat in a Monday triage call knows the unspoken rule: you have roughly a quarter to patch the embarrassing stuff before someone weaponizes it. That rule just got buried. A new metrics project called the Zero-Day Clock claims the mean time from public disclosure to in-the-wild exploitation has collapsed from nearly a year in 2021 to a little over twenty-four hours in 2026. Patch windows built for human attackers are getting demolished by attacker tooling that doesn't sleep.

What Happened

The Zero-Day Clock is a measurement effort launched by Sergej Epp of Sysdig, with most major tech and cybersecurity vendors signed on as supporters. Its single job is to put numbers on something the industry has been gesturing at for two years: AI-assisted exploit generation is compressing the defender's reaction window into something close to zero.

As Tom's Hardware reported, the mean interval between vulnerability discovery and exploitation has dropped from roughly a year in 2021 to just over a day this year. The ZDC's forward projection is uglier: one hour by 2027, eventually one minute.

The composition of the threat has shifted too. Five years ago, 31% of exploits were zero-days, meaning attackers were already using them before disclosure. Today that number is 73.2%. The flip side is what the data calls non-exploited vulnerabilities, the bugs that get reported and quietly die without anyone bothering to weaponize them. That category sat around 60 to 70% in 2021 and is now down to 25% at the moment of disclosure. Push the timeline out six weeks and zero vulnerabilities remain unused, versus roughly 24% for last year's cohort.

The researchers are clear about what they can and can't see. "We only track publicly visible exploits. Private or nation-state exploits may exist earlier," they note. So treat the numbers as a floor, not a ceiling. The real curve is steeper.

Technical Anatomy

Why is the clock running this fast? Two structural reasons converge.

First, the raw substrate of modern software is still unsafe. The ZDC pins 70% of vulnerabilities on memory safety bugs. That's the same buffer-overflow, use-after-free family of issues we've been failing to fix since the 1990s. AI tooling didn't invent these classes of bugs. It just industrialized the process of finding them. A model that can read a diff, identify the unsafe pointer arithmetic, and emit a working proof-of-concept turns what used to be a senior reverse-engineer's week into a script run.

Second, the disclosure pipeline itself leaks signal. The industry-standard 90-day disclosure window was designed for a world where exploit development took weeks of skilled labor. When generation time drops below patch deployment time, the disclosure becomes a starting gun for the attacker, not the defender. The CISA KEV catalog has been showing this pattern for months: vulnerabilities are landing in the actively-exploited list within days of CVE assignment, not quarters.

The ZDC's recommended technical countermeasures map directly to these two pressures. On the substrate side: move off C and C++ to Rust or another memory-safe language, ship with all security features enabled by default, adopt zero-trust architecture, and design systems to be disposable so a compromised host can be torched and rebuilt in minutes. On the tooling side: open-source AI defensive tools so defenders have parity with attackers, who already have access to the same models.

Coverage of Anthropic's Mythos bot described it as a proverbial superweapon. My take: if one lab's internal tool earns that label, you should assume three nation-state equivalents already exist, and at least one criminal-market version is being rented by the hour. The asymmetry isn't capability, it's distribution.

Who Gets Burned

The collapse hits unevenly. Teams running modern, containerized, frequently-rebuilt infrastructure absorb a one-day exploit window better than teams running long-lived VMs with quarterly patch cycles. That maps poorly to a lot of the verticals reading this.

iGaming platforms are particularly exposed. Live betting infrastructure runs hot, payment integrations are sprawling, and regulatory constraints often slow down emergency patching because every change requires compliance sign-off in multiple jurisdictions. A 24-hour exploit window against a stack that takes 72 hours to push a regulated config change is a structural mismatch. The production incidents I've seen in this space usually trace back to a third-party SDK or odds-feed integration nobody on the core team owns. Those vendors now need to be on the same clock.

Fintech sits in a similar bind. PCI scope, change-advisory-board theatre, and core banking partners who deploy on their own glacial schedule mean the weakest link sets your real patch latency. The uncomfortable read: if your KYC vendor patches monthly, your effective exposure window is monthly, regardless of how fast your own pipeline runs.

Crypto and DeFi teams have the opposite problem. They patch fast, but immutable contracts can't be patched at all. When the exploit window drops to an hour, the entire defensive posture has to shift to circuit breakers, pausable contracts, and aggressive monitoring of the mempool. Code that can't be changed needs infrastructure around it that can.

Enterprise infrastructure vendors face the liability question head-on. Bruce Schneier's line in the ZDC report is blunt: "No industry in the past 150 years has improved safety or security without being forced to by the government." He also points out that insecure, first-to-market products beat better-built competitors every time. If liability legislation lands, the economic incentives finally flip. If it doesn't, the race to the bottom continues.

Playbook for Security Teams

Concrete actions for the next two weeks, ordered by use:

Audit your real patch latency, not your stated one. Pick the last ten CVEs that affected your stack. Measure wall-clock time from CVE publication to production deployment. If the median is over 48 hours, the ZDC numbers say you're already losing. Identify the bottleneck: vendor lag, CAB process, regression testing, or rollout windows.

Inventory your C and C++ exposure. 70% of vulnerabilities being memory safety bugs is a planning input, not trivia. Identify which services in your critical path are still in unsafe languages. You're not rewriting them this quarter, but you should know which ones are the highest-value Rust migration candidates over the next year.

Make hosts disposable. If rebuilding a compromised production node takes more than fifteen minutes, fix that before you buy another EDR license. Disposability is the cheapest mitigation against an exploit you couldn't have patched in time anyway.

Wire up KEV-driven alerting. Subscribe to the MITRE CVE feeds and CISA KEV updates directly into your on-call rotation, not just a Slack channel nobody reads at 2am. When the exploit window is a day, asynchronous notification isn't enough.

Pressure your vendors in writing. Add patch-SLA clauses to renewals. Sub-72-hour critical patch commitments should be table stakes. If a vendor can't agree to that, they're a liability transfer waiting to happen.

Key Takeaways

• Mean time from disclosure to exploitation dropped from ~1 year (2021) to ~1 day (2026), projected to 1 hour in 2027. The 90-day disclosure window is a relic.
• Zero-day share of exploits jumped from 31% to 73.2% in five years. Defenders are arriving after the attacker, not before.
• 70% of vulnerabilities are memory safety bugs. Rust migration of critical-path services is a strategic priority, not a nice-to-have.
• The ZDC only counts public exploits. Private and nation-state activity is by definition off the chart, so the real curve is worse.
• Disposable infrastructure, vendor patch SLAs, and KEV-driven paging beat any single shiny defensive tool for closing the gap.