For most of the last decade, the time between a vulnerability going public and that vulnerability being exploited was your working margin. It was the space where patch testing happened, where change windows got scheduled, where triage got done. New telemetry puts that margin at about two days.
A threat-hunting report published on August 3 (CrowdStrike) found that, from January through June 2026, 88 percent of the vulnerabilities it observed being exploited, among those with a public proof-of-concept, were hit within 48 hours of that PoC becoming available. This echoes the Verizon Data Breach Invesitgation report where vulnerability exploitation as surpassed most threats.
The illustrations behind the number are worth sitting with. After one critical web-application flaw was disclosed, threat hunters logged more than 800 investigation leads across upward of 80 organizations in four days. A separate Linux privilege-escalation flaw shipped with a working public exploit the same day it was disclosed, and within 24 hours it was being deployed at scale. Roughly 94 percent of that first-day activity was actors simply running the public code to see what it could do.
Two caveats keep this honest.
What two days does to a maintenance window#
The practical problem is what this timeline does to the way most teams schedule remediation. Standard change control ranks findings by severity, usually a CVSS score, and slots the critical ones into the next maintenance window. Depending on the organization, that window is weekly, biweekly, or monthly.
That cadence quietly assumes you have that long. Against a two-day exploitation curve, the maintenance window stops being a safety buffer and becomes the exposure itself.
This isn’t a story about negligent teams. The maintenance-window model exists for good reasons: testing takes time, change advisory boards meet on a schedule, and uptime commitments are real. The model isn’t wrong so much as it was built for a tempo that no longer describes the fast-moving end of the threat landscape.
Severity answers the wrong question#
The deeper issue is which signal you prioritize on. Severity tells you how bad it would be if a flaw were exploited. It says nothing about how soon.
Whether a working proof-of-concept is publicly available is the variable that actually predicts near-term timing, and most prioritization schemes don’t weight it at all. A medium-severity bug with a public PoC and a reachable path in your environment can carry more immediate risk than a critical with no public exploit code in existence. One is a timing problem this week. The other may be a timing problem never.
That distinction is easy to state and surprisingly hard to operationalize, because most vulnerability management tooling leads with the severity number. The severity number is where the eye goes, and it’s usually where the SLA clock is anchored too.
The supply-chain slice, in real time#
The same report found that npm packages accounted for 87 percent of the software-registry threats it identified in the first half of 2026. The day after the report published, a self-propagating worm tore through hundreds of npm packages, stealing credentials from developer and build environments as it moved from one maintainer to the next.
The report described the pattern on a Monday. The ecosystem demonstrated it on a Tuesday.
For this class of risk, patch cadence isn’t even the right frame. A poisoned dependency carrying an install-time script can execute inside your pipeline before a human ever reviews the version bump. The window there isn’t two days. It’s however long your CI takes to run an install.
A few adjustments worth making#
None of this calls for patching everything in an afternoon, which isn’t possible anyway. It calls for a handful of specific changes.
Add proof-of-concept availability as an explicit input to prioritization, sitting alongside severity rather than behind it. When a public PoC exists for something reachable in your environment, it should jump the queue regardless of what the maintenance calendar says.
Decide your emergency-change path in advance for known-critical assets. You can’t compress testing to hours across the board, but you can pre-designate which systems warrant expedited handling, so you’re making that call before an incident rather than during one.
For dependencies, watch install-time behavior, not just version numbers. The most useful early signal in this batch of supply-chain attacks was a package changing what it does at install time between versions. That’s a standing detection rule rather than a patch, and it moves at the speed the attacks actually move.
Check your remediation SLAs against this timeline directly. If your service level for a critical finding with a public exploit is written in weeks, the data is telling you the SLA is the gap.
The number that’s shrinking is the distance between “known” and “exploited.” That’s the one worth measuring in your own environment, with current data rather than last year’s assumptions about how much time a disclosure buys you.
Figures cited are drawn from the CrowdStrike 2026 Threat Hunting Report (August 3, 2026). The npm worm referenced is the keyv and cacheable package compromise disclosed August 4, 2026.
