CyphrQ
Menu

How Fast Are Vulnerabilities Exploited? Time to Exploit and Emergency Patching

Attackers now often exploit flaws before or within days of a patch. Time to exploit explained, zero-days vs n-days, and an emergency patching plan.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

Time to exploit is the gap between a security flaw becoming known and attackers using it. That gap has collapsed: Mandiant's M-Trends 2026, drawn from its 2025 incident investigations, estimates the mean at minus seven days, so exploitation often begins before a fix exists. The practical answer is to decide now, before the next critical flaw lands, who calls an emergency, what gets patched first, what you do when you can't patch, and how you check you weren't already hit.

How to score and rank ordinary patches is in our guide to CVSS, EPSS and KEV. Recently exploited flaws are on the latest exploited vulnerabilities page.

What does "time to exploit" mean?

Google's Mandiant team defines time to exploit (TTE) as "the average time taken to exploit a vulnerability before or after a patch is released." A positive number means attackers moved after the vendor shipped a fix. A negative number means they were already using the flaw before any fix was available.

It is an average across many flaws, not a promise about any single one.

How fast are vulnerabilities exploited now?

Faster every time it has been measured. Each figure is from the publisher's own page, read 27 October 2026.

Period Figure Source
2018-2019 Average TTE of 63 days Mandiant, 2023 TTE analysis
2020 to early 2021 44 days Same
2021-2022 32 days Same
2023 5 days (47 days if 15 outliers are kept in) Same, published 16 October 2024
2025 investigations Mean "an estimated -7 days" Mandiant M-Trends 2026, published 24 March 2026

Two notes on reading this table. First, the 2023 figure depends on method: Mandiant removed 15 statistical outliers, 13 of them zero-days, and says that "without the removal of these outlier TTEs, the average grows from five to 47." Second, M-Trends describes its figure as an estimate. The report draws on Mandiant's 2025 investigations, though the page doesn't give a separate date range for this figure. Its summary says exploitation "is routinely occurring before a patch is even released."

The volume is rising too. Google Threat Intelligence Group (GTIG) recorded 141 distinct vulnerabilities disclosed and exploited from January to August 2026, more than the 127 it counted for all of 2025. In GTIG's own monthly averages, that is 18 a month from January to August 2026, up from 10.5 a month in 2025.

What is the difference between a zero-day and an n-day?

The difference is whether a fix existed when attacks began.

  • A zero-day is a flaw exploited before the vendor has made a patch available. Mandiant's definition leaves out end-of-life technologies.
  • An n-day is a flaw first exploited after a patch is out.

For a zero-day, you cannot patch your way out on day one. You rely on mitigations, monitoring and the vendor's guidance until the fix ships. For an n-day, the fix exists and the race is whether you apply it before an attacker reaches you.

Zero-days are the larger share of what gets exploited. Of the 138 exploited vulnerabilities disclosed in 2023 that Mandiant analysed, 97 were exploited as zero-days and 41 as n-days. GTIG's 2026 data shows the same pattern: zero-days made up 62% of observed exploited vulnerabilities from January to August 2026.

The n-days still move quickly. In Mandiant's 2023 data, 12% of n-days were exploited within one day, 29% within one week, and 56% within one month. Mandiant found that exploitation "was most likely to occur within the first month of a patch being made available."

In practice: one flaw, six groups, one week. GTIG describes a BeyondTrust vulnerability, CVE-2026-1731, where "within four days of public disclosure, GTIG observed a threat cluster exploiting this vulnerability, followed by five additional threat clusters within seven days of public disclosure." A monthly patch cycle would have left that window wide open.

In practice: zero-days aim at business systems. GTIG's review of 2025 zero-days, published 6 March 2026, tracked 90 zero-days exploited that year, against 78 in 2024 and a record 100 in 2023. Of the 90, 43 (48%) affected enterprise software and appliances, an all-time high in both number and share, and about half of those (21) were in security and networking products. Why edge devices such as VPNs and firewalls attract so much of this is covered in our post on exploited edge devices.

Do I need to patch everything this fast?

No, and trying to will exhaust your team. Most disclosed flaws are never used in an attack. GTIG says only 0.23% of all vulnerabilities disclosed in 2026 (its data runs from January to August) were observed in active exploitation, which it describes as "on the order of tens versus thousands per month."

So run two speeds:

  1. Normal speed for the steady flow of updates. The UK NCSC's vulnerability management guidance recommends a policy to "update by default", with targets of 5 days for internet-facing services, 7 days for operating systems and applications, and 14 days for internal or air-gapped systems. The NCSC says these timescales apply "regardless of the vulnerability severity."
  2. Emergency speed for the few flaws that are exploited, or very likely to be, on systems you run. For those, the NCSC says "the timelines above are too long and it is essential to speed up the update process."

Who decides when a vulnerability is an emergency?

Name one person, in advance, who can declare a patching emergency without waiting for a meeting. In a small business that may be the IT lead or your managed service provider's named contact. In a larger organisation it is usually the security lead, with an agreed deputy.

Write down three things for that role:

  • The trigger. For example: a flaw is in CISA's Known Exploited Vulnerabilities (KEV) catalogue or a national cyber agency advisory, and it affects a product you run, especially one reachable from the internet.
  • The authority. Permission to apply an emergency change, restart a service out of hours, or take a system offline, with the business owner told rather than asked.
  • The deadline for a decision. A target of hours, not days, for "patch, mitigate or isolate."

The point is to remove the delay that comes from finding out who is allowed to say yes.

What do you patch first?

Work outward from the attacker's view of you:

  1. Internet-facing systems running the affected product. VPNs, firewalls, remote access tools, web servers, email gateways and file-transfer services come first.
  2. Systems that hold the keys. Identity servers, management consoles and backup systems, because compromising one of them can hand an attacker the rest.
  3. Everything else running the affected version, internal systems included.

You can only do this quickly if you already know where the product runs. An up-to-date asset list, including which systems face the internet, is the one piece of preparation that pays for itself in every emergency. GTIG's 2025 zero-day review also recommends keeping a software bill of materials (SBOM), a list of the components inside your software, so you can find a vulnerable library such as Log4j across your estate.

In practice: a worked example. Our php2shell write-up applies this order to a real case: find every PHP install, internet-facing first, update to a fixed version, and use the interim settings while you can't.

What if you can't patch yet?

Sometimes there is no patch yet, or the patch needs a maintenance window you can't get today. Then reduce exposure while you wait:

  • Take it off the internet. CISA's BOD 26-04, its current directive for US federal agencies, says that "one valid mitigation is to remove the system from the internet."
  • Switch off the vulnerable feature. GTIG's 2025 zero-day review advises that if a patch is unavailable, you isolate systems "with stop-gap measures such as disabling specific services or blocking specific ports at the perimeter."
  • Apply the vendor's interim guidance exactly as written, and note that vendors often say it reduces risk rather than removes it.
  • Watch it closely until the fix is in.

If a vulnerable system can't be patched or isolated at all, treat that as a business risk decision for its owner to sign, not a technical footnote.

How do you check you weren't already hit?

Because exploitation often starts before a patch, patching closes the door but does not tell you whether someone already walked through it. The NCSC's advice for an internet-facing service under active exploitation is to "investigate your exposure and check for signs of compromise before applying any update, even if the exposure was brief."

At minimum:

  • Check the vendor and agency advisories for indicators of compromise, the specific files, accounts or network addresses linked to the attack.
  • Review logs from before you patched, going back to at least the date the flaw was first reported as exploited.
  • Look for new admin accounts, unexpected configuration changes and unfamiliar files on the affected system.
  • Get incident response help if anything looks wrong.

How a quiet intrusion unfolds after first access is set out in our guide to the data breach lifecycle. The tools that might have seen it, and their blind spots, are compared in our post on breach detection tools.

Going deeper: for security and IT teams

What replaced CISA BOD 22-01?

CISA's BOD 26-04, "Prioritizing Security Updates Based on Risk", issued 10 June 2026, replaced BOD 22-01 and BOD 19-02.

The directive "supersedes and hereby revokes" both, so older guidance that quotes BOD 22-01's fixed deadlines is out of date. It binds federal civilian agencies, not private companies, but it is a useful model. Points from the directive text:

  • Remediation timelines are in calendar days and start when CISA adds a vulnerability to KEV or when the agency identifies it on an asset in its CDM (Continuous Diagnostics and Mitigation) dashboards, "whichever event occurs first."
  • Some KEV entries now carry a three-day deadline marked "& forensic triage": the agency must remediate or mitigate within three days and "carry out a forensic triage of the asset to assess whether the system is compromised."
  • Timelines move with the facts. Taking a system off the internet changes its "Publicly Exposed" value and can lengthen the deadline.
  • At the low end, "fix on system upgrade" items are remediated at the asset's next scheduled major upgrade or rebuild.
  • Table 1, which maps each risk combination to its deadline, is published as an image, so its rows are not listed here. Check the per-entry due date in the live KEV catalogue instead.

Forensic triage, as CISA sequences it. The BOD 26-04 implementation guidance gives six steps with recommended (not mandatory) time windows: scoping in the first two hours; preserve and collect evidence (2-24 hours), with the instruction "do not alter or remediate systems prior to evidence/artifact collection when possible"; critical patching and stabilisation (2-24 hours), noting "patching may jeopardize the availability of artifacts"; contain and control (6-24 hours), done "in a manner that does not alert the threat actor"; triage analysis (24-48 hours); and an escalation decision with a written triage report (48-72 hours). The order matters: capture memory, disk images and device logs before you patch or reboot, because a restart can wipe volatile evidence.

No exceptions, only isolation. The same guidance says CISA "does not issue waivers or exceptions" for required actions. Where the catalogue's required action cannot be completed in time, agencies should remove the asset from the network, with options including decommissioning, removing the vulnerable product, segmentation, software-defined perimeters and proxies. For third-party products, contact the vendor directly for the patch or operational guidance.

Reading the measurements correctly. The figures come from different datasets and should not be mixed. Mandiant's TTE counts exploited vulnerabilities its analysts tracked, with outlier handling that moves the 2023 average from 5 to 47 days. GTIG's 2026 counts use GTIG's own risk ratings, not CVSS. VulnCheck's State of Exploitation 2026, published 21 January 2026, found that "28.96% of KEVs in 2025 were exploited on or before the day their CVE was published." That figure uses VulnCheck's own KEV list (884 entries for 2025), which is broader than CISA's. The common conclusion is direction, not a single number: plan for exploitation on or before disclosure day.

Architecture that buys time. GTIG's zero-day review recommends segmenting DMZs, firewalls and VPNs from domain controllers and the core network, not exposing device ports to the internet unless strictly required, and deploying canary tokens and files to catch lateral movement. These controls matter most during the zero-day window, when no patch exists.

Measure your own clock. For each emergency, record the time from advisory to decision, decision to mitigation, and mitigation to verified patch, plus whether triage found compromise. Compare your median against the NCSC's 5-day internet-facing target and any KEV due dates that applied. If your decision step alone takes longer than a day, fix the process before the tooling.

Questions for vendors and MSPs. How do you notify us of an exploited flaw, and how fast? Do your advisories include indicators of compromise and integrity-check tools? Can your appliances export logs to our central store? Who on your side can approve an out-of-hours emergency change for us?

Emergency patching checklist

  • [ ] One named person (and a deputy) can declare a patching emergency.
  • [ ] The trigger is written down: KEV listing or national advisory, plus a product you run.
  • [ ] An asset list shows where each product runs and which systems face the internet.
  • [ ] Order agreed: internet-facing, then identity and management systems, then the rest.
  • [ ] Mitigation options are pre-approved: isolate, disable the feature, block ports.
  • [ ] Evidence is collected before patching or rebooting where possible.
  • [ ] Logs from before the patch are reviewed for signs of compromise.
  • [ ] An incident response contact is on file before you need it.
  • [ ] Each emergency's timings are recorded and reviewed afterwards.

Key takeaways

  • Time to exploit is the average time attackers take to exploit a flaw before or after its patch. Mandiant's M-Trends 2026 estimates the mean at -7 days; Mandiant's earlier analysis measured 63 days for 2018-2019.
  • Zero-days are exploited before a fix exists; n-days after. In Mandiant's 2023 data, 56% of n-days were exploited within a month of the patch.
  • Only a tiny share of disclosed flaws, 0.23% in GTIG's 2026 count, are exploited, so run a normal patch speed and an emergency one.
  • Decide in advance who declares an emergency, patch internet-facing systems first, isolate when you can't patch, and check for compromise as well as patching.
  • CISA's BOD 26-04 replaced BOD 22-01 on 10 June 2026; some KEV entries now carry a three-day deadline plus a forensic triage.

Sources

All pages read 27 October 2026.