Time to Exploit: How Fast Attackers Weaponize New CVEs

Time to exploit is not a countdown that starts when your scanner opens a ticket. Attackers may already be working while your team is still deciding who owns the system.

The practical problem is not that every new CVE becomes an emergency. Most do not. The problem is that the few vulnerabilities attackers weaponize quickly look identical to routine findings during the first hours. A useful program has to separate those cases before a normal patch calendar consumes the available response window.

That requires two clocks. The attacker clock measures the interval between discovery, disclosure, and observed exploitation. The defender clock measures how long it takes to match affected assets, judge exposure, approve an action, deploy it, and prove the risky state is gone. Risk lives in the gap between those clocks.

What does time to exploit actually measure?

Time to exploit usually means the interval between public disclosure and the first confirmed exploitation of a vulnerability. The number can be positive, zero, or negative. Positive means exploitation was observed after disclosure. Zero means it happened on the disclosure date. Negative means an attacker used the flaw before the public knew enough to start a normal response.

Treat that definition carefully. First observed exploitation is not first exploitation. It is the earliest event a source could validate. A quiet campaign may run for weeks before a victim, vendor, or researcher finds it. The clock is an evidence boundary, not perfect history.

It also differs from time to weaponize. A researcher can publish a working demonstration without evidence that criminals used it. Attackers can exploit a flaw privately without public code. The distinction matters because proof of concept, functional exploit, and observed abuse deserve different routing. Our guide to a proof of concept exploit explains how to test that evidence without treating every repository as active attack data.

How fast are attackers exploiting vulnerabilities in 2026?

There is no honest universal average. The population is lopsided. Thousands of CVEs never see practical abuse, while a small set moves before a fix exists. A single mean hides that shape.

Still, the direction is clear. Mandiant published its AI assisted vulnerability management blueprint on July 16, 2026. It cites M Trends 2026 and reports a mean time to exploit of negative seven days. In plain terms, exploitation in the measured cases often began a week before a patch was available. That does not mean every CVE is a zero day. It means a program built only around disclosure cannot win every race.

Verizon published the 2026 Data Breach Investigations Report findings on May 19, 2026. Vulnerability exploitation started 31 percent of breaches, passing stolen credentials as the leading entry point for the first time in the report's 19 years. Speed matters because exploitation is no longer a secondary path. It is the front door in almost one breach out of three.

The most useful recent development is a better forecast, not another severity label. FIRST began publishing EPSS v5 on June 15, 2026, according to its official EPSS data history. EPSS estimates the probability of exploitation in the next 30 days and refreshes daily. Version changes can shift scores, so historical decisions need the model version and score date. A naked score in a ticket is not enough evidence.

Which signals predict a compressed exploit window?

No single signal predicts speed reliably. Use a stack, and make the strongest evidence win.

1. Observed exploitation. A CISA Known Exploited Vulnerabilities entry or a credible incident report changes the question from likelihood to local exposure. Route it now.
2. Internet reachability. A vulnerable service reachable from the public internet gives an attacker cheap discovery and repeatable delivery. An isolated lab host does not share that clock.
3. Exploit maturity. Working public code, reliable authentication bypass, and low complexity shorten attacker work. A crash demonstration is weaker evidence than repeatable remote code execution.
4. Forecast movement. A high or sharply rising EPSS score can surface momentum before a KEV listing. Keep the date because the score can change tomorrow.
5. Business consequence. Identity systems, edge appliances, and administrative consoles can create more damage per successful exploit than a disposable workstation.

CISA's live KEV catalog released version 2026.08.31 with 1,687 entries. Of those, 352 had known ransomware campaign use, and 281 were added during the prior 12 months. That is a small, changing subset of the full CVE population. The operating lesson is not to patch 1,687 items blindly. It is to match the catalog to assets you actually run and escalate the intersection.

How do you check exploit probability without opening a dashboard?

FIRST documents a public API for current and historical EPSS values. This read only command returns the score, percentile, and score date for one CVE:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | \
  jq '.data[] | {cve, epss, percentile, date}'

On August 30, 2026, that query returned 0.99999 for Log4Shell, at percentile 1. The command does not tell you whether a vulnerable Log4j copy exists, loads, or can receive attacker input in your environment. Join the forecast to software inventory, runtime state, network exposure, and controls. Prediction without local context just creates a faster queue.

Why does time to exploit vary so much?

Attacker economics create the spread. A flaw in a common edge appliance offers a large target set, simple discovery, and direct access. One exploit can be reused against thousands of organizations. A flaw in an uncommon desktop component that requires local access and a precise user action offers a smaller return. Both can carry a high severity score. They do not attract the same speed.

Disclosure quality changes the work too. A vendor advisory may include the affected code path, a patch diff, test cases, and enough detail to reproduce the issue. That helps defenders understand exposure, but it also reduces attacker research cost. Withholding useful detail is not a durable defense. Teams should assume public fixes will be studied and prepare the deployment path before a scheduled release.

Reachability is the accelerator organizations control. Internet search services and routine scanning make exposed products cheap to find. Authentication bypass and remote code execution need fewer steps than a flaw requiring an existing foothold. Default credentials, open management interfaces, and shared administrative access make the path cheaper again.

Defender visibility changes the observed number. A mature detection team may discover exploitation quickly, while another organization misses the same activity for months. That is why public time to exploit research should set urgency, not pretend to describe your exact first attack date. Local logs and endpoint evidence have to answer whether the behavior already happened here.

Consider two copies of the same vulnerable file transfer product. One is an internet facing gateway with customer data and a service account that can reach internal storage. The other is a powered off training system on an isolated network. The CVE, CVSS, EPSS, and public exploit date are identical. The first system belongs in containment now. The second needs recorded evidence and a planned repair. Local context converts one public clock into two defensible decisions.

What response framework fits the exploit clock?

Use four lanes. Keep the lane criteria explicit enough that an analyst and service owner reach the same answer.

Notice that a ticket does not stop the clock. Deployment does not stop it either. The clock stops when evidence shows the exposed state is gone or a control blocks the attack path. That distinction prevents a closed change request from becoming false assurance.

How much response capacity does a fast exploit consume?

Imagine an advisory affects 240 servers. Inventory and context reduce that to 40 reachable systems. Two engineers need 20 minutes per server for change, restart, and verification. That is 800 minutes, or more than 13 hours of work. With four engineers working in parallel, the minimum hands on time is about three hours and 20 minutes, before approvals or failed changes.

The math exposes the real bottleneck. A two hour response target cannot be met by asking the same four people to type faster. The organization needs prepared containment, automated deployment rings, service owner contact data, and a verification query. Build those before a critical advisory arrives.

This is why blanket urgency fails. If 500 routine findings enter the emergency lane, the team loses the capacity reserved for the 40 systems that matter. Use EPSS as a forecast, CISA KEV as confirmed threat evidence, and live system facts as the final scope test.

Which time metrics should leaders track?

One average hides the work. Track median and 90th percentile time for each stage: advisory to asset match, match to decision, decision to deployment, and deployment to verification. Split known exploitation from forecast risk and routine findings. Then count how often the team missed its target because ownership, testing, maintenance access, or evidence was unavailable.

The useful board measure is the exposure gap for the systems that could change business outcomes. A declining average across low consequence laptops can look good while an internet facing identity service waits for an owner. Report the tail, not just the center.

Frequently asked questions

Is time to exploit the same as exploit availability?

No. Exploit availability records that code or instructions exist. Time to exploit requires evidence of use, and the first observed date may still be later than the true first attack.

Can a time to exploit value be negative?

Yes. Negative time means exploitation was observed before public disclosure. The correct response is prepared containment and strong detection, since a patch may not exist yet.

Should every high EPSS vulnerability receive an emergency patch?

No. EPSS forecasts exploitation across the public population. Confirm affected software, reachable attack surface, business consequence, and controls before assigning an emergency lane.

What metric matters after a patch deploys?

Verified closure. Measure the time until the fixed version or effective mitigation is observed on every in scope asset, including systems that were offline during deployment.

Executive takeaway

Stop asking whether your patch SLA is 15 or 30 days. Ask how quickly the team can identify reachable affected systems, choose containment, deploy a safe change, and prove closure when exploitation starts before the advisory. Test that path on one internet facing service this month. If the answer depends on a spreadsheet, an inbox, and tribal knowledge, the exploit clock already has the advantage.