a16z's Chart of the Week has released exploit data that confirms what the industry as a whole has been feeling, exploits no longer surviving six weeks, with median time to exploit is heading toward one minute.
The sharp drop in the survival curve drives home the shift in cyber. In 2022, 50% of exploits were still unpatched at 1.5 months. At three months, still 50%. The curve barely moved between those points.
Today it falls to 0% by 1.5 months, meaning nothing survives six weeks anymore.
The rest of the report:
The zero-day rate has roughly quadrupled since 2020. It rose ± 60% in the last year alone, now it’s just under 87%.
Median time to exploit is one day, projected to compress to about one minute within the year.
Critical and high-severity vulnerability volume went vertical starting spring 2026, per Epoch AI. a16z flags its own caveat, that some of the jump could be reporting or definition changes rather than pure growth.
Those are a16z's numbers and there’s nothing to add to them. What can be added is a measurement of the same thing taken from the other side.
The Race
Last month we ran the AI Hacking Race: 7 off-the-shelf models, 4 isolated targets (Grafana, two Jenkins variants, Nextcloud), 105 runs carried through to a defined end condition.
Benchmarks deserve scrutiny, ours included, so here is how we tried to make it hard to fool ourselves.
Against the vulnerable targets, 36 of 77 runs reached remote code execution - that's 47%. Verification did not rely on a model reporting its own success.
Each run had to return a cryptographic fingerprint from the target.
That distinction does matter since agents are fluent narrators of their own progress, and will describe an intrusion that never happened in confident detail. A fingerprint the agent could only obtain from inside the target settles it, the run either brings back the value or it doesn’t.
We published the misses alongside the wins, because a control group that never fails is not a control group.
Plenty of published results show a model finding something, and some show what the same model does against code where there is nothing to find. Without that second number, a benchmark cannot separate a capable agent from an enthusiastic one.
Control Beat Effort
The efficiency numbers were the ones I did not expect. Median verified run: 34 Bash commands, 4.4 minutes of active time. Median failed run: 110 commands, 18.7 minutes. The runs that found nothing worked three times harder and took four times longer.
Success looked quiet. The models that got in read the environment, formed a hypothesis, and committed to one path. Failure looked like enumeration without direction: more scanning, more probing, more commands, less progress.
There is a detection consequence sitting in that gap. Command volume is a poor proxy for how much trouble you are in. A team tuning alerts around noisy reconnaissance is building a threshold that the fast verified compromise passes underneath. The 34-command run is the one that worked.
Top performer was GPT 5.6 Sol: 9 of 11 confirmed, median 2 minutes 16 seconds, $149.21. Second was GLM 5.3: 8 of 11 confirmed, median 10 minutes 9 seconds, $51.82. GLM gave up one confirmed RCE. It took four and a half times as long and cost a third as much. Speed and cost are separate axes, price tells you very little about how fast the answer arrives.
Our position on what counts as done: naming a bug is not the finish line. Demonstrated control is, verified by something other than the agent's own account.
What the Race Does Not Show
The targets were known-vulnerable, widely deployed software in isolated environments. That is not a hardened production estate. Nobody was defending them, so there was no segmentation, no rate limiting, no endpoint tooling, and no analyst watching a console. The models also started from a clean position with the target in front of them. Real intrusions spend most of their time getting to that position.
The sample is also modest. Eleven runs per model against this target set gives a median that moves with a couple of unlucky attempts. Treat the individual model rankings as directional.
So the Race measures one step: exploitation, once a real gap is in reach. That narrowness is deliberate. Exploitation is the step a16z's chart is compressing.
The Same Clock
a16z is measuring the attacker from the outside, in aggregate, after the fact. Exploitation compressing toward a minute, patch windows collapsing to zero.
We measured it from the inside, on our own targets, under conditions we controlled. Off-the-shelf models, no custom tooling. A median of 4.4 minutes to a verified exploit against a real gap. Nothing at all against code that is actually patched.
Two independent measurements leading to the same conclusion.
A one-day median time to exploit still assumes a defender who patches faster than most teams manage.
A 4.4-minute median assumes nothing about the defender at all.
For most security teams, the working assumption has been that a patch record is close enough to a patched system. Change tickets, version bumps, a scanner that stops reporting the CVE. That assumption held for years, mostly because verifying it cost more than the risk of being wrong. The survival curve is what happened to that arithmetic.
The distinction that matters is no longer patched versus unpatched. It is patched versus proven patched. That gap used to be one you could close slowly, by waiting to see whether anything happened. a16z's curve says there is no longer time to find out that way. Our own runs, failures and methodology included, say the same thing from the other direction.