"The average time to exploit vulnerabilities is now negative."
If you work anywhere near vulnerability management, you've heard some version of this.
Often, vendors cite Mandiant’s 2026 M-Trends report, which estimates that the mean time-to-exploit (TTE) for new CVEs is -7 days. Other sources put it anywhere from -23 hours to a few hours.
While you’re reeling from that gut punch, they wind up the real haymaker:
“...and attackers use AI now, so they can exploit CVEs before patches are available.”
Presumably, security teams should think, “Wow, if that’s true, we’ll have to patch really fast!”
Except, that wouldn’t work, would it?
Is vulnerability management cooked?
If new CVEs were exploited en masse before anyone knew about them, vulnerability management would be a waste of time. Even the mass replacement of patching with faster mitigations would be too little, too late.
If we accept these claims uncritically, they might lead us to conclude:
- Vulnerabilities are exploited hours or days before you know about them
- Exploitation happens en masse before you can respond
- This is the typical experience for organisations and their security teams
But first-hand experience suggests this can’t be true. Did your organisation get breached over and over this year due to CVE exploits? How about all the organizations you interact with?
If not… why not?
Why “average” is anything but
The IT security industry is fortunate to have some outstanding research resources, including Mandiant’s reports. Unfortunately, the industry at large also has a tendency to take evidence-based data points, add some dubious claims, and conclude the sky is falling.
A negative TTE doesn’t mean a vulnerability will be exploited everywhere before it’s published as a CVE. Just that exploit activity begins pre-publication.
That still sounds scary, but ask yourself: Does it seem likely that attackers are exploiting CVEs in significant numbers before they are disclosed? Wouldn’t the exploit activity itself prompt investigation that would result in a CVE being published?
Well… yes. That’s how it often works.
In fact, there are cases where a vulnerability is exploited months or years before it becomes a CVE. This is possible only because the initial exploit activity is very limited in scope, and not enough to prompt a thorough investigation that would result in a CVE being published. (Still, these fringe cases can significantly affect overall TTE figures.)
When Mandiant says that mean TTE is now -7 days, they’re really talking about the mean Time To First Exploit (TTFE), or even Time To First Known Exploit (TTFKE). This is not a timeline for mass exploitation, but for the first observed exploit activity relating to newly published CVEs.
In our view, a raw TTE/TTFE figure is not particularly useful for understanding a typical organisation's real-world exposure. These figures may be a mean average, but they don’t represent the average defender’s experience.
A more helpful approach would be to look at how exploit activity is spread over time, whether that’s changing, and how quickly organisations would need to respond (once able) to minimise risk. Ideally, we’d draw some sensible conclusions from real-world exploit activity that will help defenders deal with the rising threat of CVE exploitation.
New isn’t everything
The 2026 Verizon DBIR found that exploiting vulnerabilities was the most common initial access vector in breaches, present in 31% of data breaches. That makes it almost twice as prevalent as phishing (16%), the next most common vector.
So CVEs matter. The question is which CVEs, and when?
As of February 2026, the CISA KEV Catalog listed 1,526 CVEs, of which 991 saw exploit activity in the previous year. New CVEs made up 69% of KEV additions in that period, but just 17.4% of all exploited CVEs. Of the CVEs with persistent exploit activity, 80% were published before 2024, meaning defenders had, in theory, quite a bit of time to remediate them.
Meanwhile, newly published CVEs seeing exploitation activity have fallen sharply, from 620 in 2024 (1.52% of that year's CVEs) to 483 in 2025 (0.97%), and just 118 as of August 2026 (0.25%).
In short, new CVEs represent a small proportion of exploited CVEs, and a small proportion of repeatedly exploited CVEs. So, even if mass exploitation of new CVEs did routinely happen pre-publication, it would only affect a relatively small proportion of exploit activity.
Tracking CVE exploit activity
Logic suggests that mass exploit activity can’t be happening before CVE disclosure in most cases, since the activity itself would quickly lead to disclosure. Still, it’s one thing to know that exploit activity is spread over time, and another to observe what it looks like in practice.
For example, React2Shell (CVE-2025-55182) was disclosed on 3rd December 2025, and exploit activity appeared within hours. Yet research from Cloudflare and the CSIR Fourth Paradigm Institute shows the first real spike came five days later, with much of the activity landing in weeks two to four.
Data from the DScope internet telescope and academic work such as The CVE Wayback Machine tell a similar story. Even when initial exploit activity precedes CVE disclosure, the vast majority of exploit activity happens after disclosure.
It’s worth noting that heavy exploit activity can follow very closely after disclosure (i.e., within days), but it’s not true to say that CVEs are routinely being mass-exploited before defenders can react.
In the report, we look at various datasets and cover several high profile examples to understand:
- What does CVE exploit activity over time really look like?
- Why does TTE differ so radically from the average defender’s experience?
- Is it really TTE (or even zero days) that we should be worried about?
Spoiler: it’s much more important to focus on what makes a CVE dangerous for you than to worry about industry-level metrics like TTE.
How does AI change CVE exploitation?
AI is clearly affecting vulnerability management, most obviously through the massive rise in CVE discovery volume. Its effect on exploitation is less clear.
The 2026 DBIR found most AI-assisted malware was tied to well-known attack techniques, with just 2.5% of observations involving less common techniques. Researchers at the Cambridge Cybercrime Centre found little evidence that AI is causing widespread disruption in the cybercrime underground, and noted it helps already skilled actors far more than beginners.
That mirrors what we see in bug bounty. As ethical hacker and Bug Bounty hunter Brumens, put it: "LLMs are far more useful for an experienced hacker compared to a beginner."
In the report, we turn to a variety of sources to assess:
- What evidence do we have of attackers using AI?
- Is “AI upskilling” of attackers overblown?
- Which aspects of cybercrime do (and don’t) benefit from AI?
The short answer is that AI is undoubtedly helping attackers discover vulnerabilities more quickly, identify vulnerable targets, and develop exploits. But, at least for the time being, the evidence suggests that AI tooling is affecting CVE discovery more than exploitation.
Read the full report
The tl;dr of our report is that, in most cases, defenders get some time between CVE publication and significant exploit activity. But the window is shrinking, and speed is very important. Mitigations deployed within hours or days cut risk dramatically compared with those that take weeks.
The findings are based on data from 2025 and H1 2026, so things may shift as AI develops. But at least for now, the likelihood of new CVEs being mass-exploited 7+ days before anyone knows about them is rather low.
So, what should defenders do in light of all this?
Our report digs into the whole issue of CVE exploitation in the AI era. It covers exploit timelines for specific 2025 CVEs, the economics of AI-assisted cybercrime, and why resurgent vulnerabilities deserve more attention than they get.
It also highlights five key learning points for vulnerability management teams that will help you minimise CVE exposure in the coming months and years.
Best of all, there’s no email sign-up required.
"How important is speed in vulnerability management?"
