1 minute: the exploit window we could see in 2027

An analysis published by a16z, drawing on data from Epoch AI and ZeroDayClock, put a number on something that's been felt for a while: just a few years ago, a newly disclosed vulnerability could go unexploited for weeks or even months. In 2022, half of known vulnerabilities were still unexploited even after 1.5 to 3 months of becoming public. That margin acted as a safety net: there was time to find out, patch, and move on.
That margin has practically disappeared.
According to that same analysis, the rate of vulnerabilities exploited the same day they're disclosed (or before) has quadrupled since 2020. The median time between a vulnerability becoming known and someone exploiting it is now one day. And a16z's projection points to that dropping to one minute during 2027.
One clarification worth making: that projected figure has been disputed. After the original piece was published, ZeroDayClock revised its methodology, and the most recent readings show a considerably lower percentage than the one that first circulated. The underlying trend — sustained acceleration since 2020 — holds; the exact "one minute" figure should be taken as a projection, not a settled number.
Why the cycle is compressing
The explanation isn't that there are more attackers or more motivation. It's that AI is speeding up the entire cycle: finding the vulnerability, understanding how to exploit it, and building a working exploit. What used to take an expert several days now gets resolved in hours.
And this doesn't only apply to the offensive side. The same technology accelerating attacks can accelerate defense — but only if it's built into the security process continuously, not as a one-off check.
Finding is no longer the differentiator
For years, the value of a security service was measured by its ability to find vulnerabilities. Today, finding is increasingly commoditized: any automated agent can scan a surface and return a list of findings.
The question that matters has changed. It's no longer "what did we find?" but "which of these findings are real, which ones matter first, and who makes sure the remediation actually happens?" Filtering out noise, prioritizing with expert judgment, and sustaining the fix process on an ongoing basis is the work an isolated agent still can't replace.
Why a point-in-time test arrives late by design
If exploitation time is measured in hours, a quarterly or annual testing model has a structural problem: no matter how good the results are, it's always responding to an old snapshot. A vulnerability that shows up in week two after your last test can be exploited weeks before the next one comes around.
This isn't a call to "test faster" — it's a shift in model. Validation needs to be continuous, embedded in the development flow (new assets, code changes, exposure that shifts over time), not an isolated event on the calendar.
What to do with this
Today's competitive edge isn't about reacting faster than everyone else. It's about not depending on reacting at all: having a validation and remediation process running constantly, so that when the next critical vulnerability shows up, there's already a clear — and active — path to resolving it.
Source of cited data: a16z, "Chart of the Week" (September 2026), with data from Epoch AI and ZeroDayClock.



