When time-to-exploit goes negative: what to do with your patch SLA

There is a number in M-Trends 2026 that should rewrite how we think about vulnerability management across the industry: the estimated mean time-to-exploit is negative seven days. Negative. Exploitation begins, on average, before a patch exists.

To put the shift in perspective: in 2018 that same number was 63 days. Security teams had close to two months between a vulnerability's disclosure and its exploitation to identify it, prioritize it, test the fix and deploy it. In 2024 the metric crossed zero. Today it sits at negative seven. The window did not shrink, it inverted.

What a negative time-to-exploit means

A negative time-to-exploit means that, on average, attackers are exploiting a vulnerability before the vendor publishes the patch that fixes it. The traditional mental model, a CVE is published, the race to patch begins before someone takes advantage of it, assumes the defender has a window of advantage. That assumption no longer holds. When exploitation precedes the patch, there is no race to win inside the patching framework: the exposure is already open before you have anything to apply.

I see this every week. When we run change-based testing across LatAm fintechs and payment processors, the gap between "the CVE was published" and "that CVE is already running in adversary traffic" has collapsed to near zero.

Three data points that confirm the shift

This is not an isolated metric or an optimistic reading of a single source. Three independent data points line up in the same direction.

The first: IBM X-Force 2026 reports that 40% of observed incidents started with the exploitation of a vulnerability, making it the leading cause of attacks. The second: according to VulnCheck's exploitation trend data, 28.3% of the CVEs that were exploited were weaponized within 24 hours of their public disclosure. The third is not a figure but a structural change: the research-to-weaponize pipeline that used to take weeks now runs in AI-driven exploit marketplaces, often before the advisory reaches your team.

What most analyses miss is that this is not about more sophisticated attackers. It is about industrialization. The pipeline turned into an assembly line.

Why your 72-hour patch SLA no longer holds

The 72-hour patch SLA  -the Service Level Agreement that defines how quickly an organization commits to applying a patch- was calibrated for a world in which that pipeline took two weeks. That world ended. Not because the policy is badly written, but because it measures against a window that no longer exists.

When I sit with CISOs, the gap I see most often is not in the patch policy itself. It sits between policy and operational reality, and that is exactly the gap attackers are already inside. So the honest question is not what your SLA is, but another one: what is your real mean time to patch a CVE in your externally exposed inventory? Not the SLA. The real number. If you don't know it, you can't close it.

What to do when the attacker arrives before the patch

If exploitation precedes the patch, defense cannot depend on patching speed. It has to rest on knowing, continuously, what is exposed and how it could be exploited, without waiting for an advisory to be published. That moves the conversation from reactive patch management toward continuous validation of real exposure.

At Strike we have spent the last year arguing that continuous hybrid validation has stopped being a feature: it is the new floor. When attackers work before your patch window opens, your testing has to as well. They aren't waiting for your patch window. They're working before it opens.

‍