The vulnerability management model that most organizations still operate under was designed for a world where the time between disclosure and exploitation was measured in weeks or months. A vendor would release a patch. The security team would assess the CVE. The change advisory board would schedule a maintenance window. The operations team would deploy the patch during off-hours. The whole cycle might take two to four weeks, and that was considered acceptable because attackers were assumed to need comparable time to develop and deploy exploits.
That model is now empirically false. The data from the past five years shows a consistent trend toward near-zero time-to-exploitation for critical vulnerabilities in internet-facing software, and the trend is accelerating.
The Timeline Evidence
Log4Shell (CVE-2021-44228), December 2021. The vulnerability in Apache Log4j 2's JNDI lookup feature was publicly disclosed on December 9, 2021. Cloudflare's retrospective analysis identified exploitation attempts in their telemetry as early as December 1 , eight days before public disclosure , though these may have been researcher probing rather than adversarial exploitation. By December 10, one day after the public advisory, mass scanning and exploitation was widespread. Greynoise observed exploitation from over 100 unique IP addresses within 24 hours of disclosure. By December 12, multiple ransomware families had integrated Log4Shell into their delivery chains. The total time from public advisory to commodity exploitation was roughly 24 hours. The time from advisory to mass scanning was under 12 hours.
ProxyLogon (CVE-2021-26855), March 2021. Microsoft patched a set of Exchange Server vulnerabilities on March 2, 2021. Within 48 hours, researchers at DEVCORE (who had reported the vulnerabilities) and other groups observed mass exploitation. By March 5, ESET was tracking at least 10 distinct threat groups exploiting the vulnerabilities. Microsoft estimated that at least 30,000 organizations in the United States had been compromised in the initial wave. The exploitation was so rapid that it outpaced not just patching, but even awareness , many organizations did not know they ran a vulnerable Exchange version until they were already compromised.
MOVEit Transfer (CVE-2023-34362), May-June 2023. This case is particularly instructive because the Cl0p ransomware group appears to have been exploiting the vulnerability before it was publicly disclosed or patched. Progress Software released an advisory on May 31, 2023, but forensic analysis by Mandiant found evidence of exploitation as early as May 27 , and possibly as early as July 2021 in testing phases. By the time the CVE was assigned and patches were available, Cl0p had already exfiltrated data from hundreds of organizations. The "disclosure to exploitation" window was not merely short; it was negative.
Citrix Bleed (CVE-2023-4966), October 2023. Citrix issued a patch on October 10, 2023. Mandiant later determined that exploitation had been occurring since at least late August , more than six weeks before the patch. After the patch release and public PoC availability, mass exploitation accelerated further. LockBit and other ransomware groups weaponized it within days. Organizations that patched within a week of the advisory were still at risk because pre-existing sessions needed to be invalidated, a step not mentioned in the initial advisory.
The pattern across these incidents is consistent: by the time a patch is available, exploitation is either already occurring or begins within hours.
Why the Window Keeps Collapsing
Several structural changes have driven the exploitation timeline from weeks to hours:
Diff-based exploit development. When a vendor publishes a patch, the patch itself reveals the vulnerability. Security researchers and attackers alike can diff the patched version against the unpatched version and identify exactly what changed. For simple vulnerabilities , a missing input validation check, a boundary condition error, an authentication bypass , the diff is sufficient to reconstruct a working exploit without any independent discovery. The vendor's fix is, paradoxically, an exploit development guide.
Automated scanning infrastructure. The cost of scanning the entire IPv4 address space for a specific vulnerability has dropped to near zero. Tools like Masscan can enumerate every host on a given port in minutes. Nuclei templates for new CVEs appear on GitHub within hours of disclosure, often contributed by the same researchers who reported the vulnerability. Shodan and Censys maintain continuously-updated indices of internet-facing services, including version fingerprints. An attacker who wants to find every vulnerable Exchange server on the internet can do so in less time than it takes most organizations to read the advisory.
Exploit commoditization. Fifteen years ago, exploit development was a specialized skill concentrated in a small community. Today, exploit frameworks (Metasploit, Cobalt Strike, and their underground equivalents) provide standardized interfaces for integrating new vulnerabilities. The developer of a PoC exploit needs only to produce a module that fits the framework's API. Distribution to thousands of operators happens through existing infrastructure. The time between "working PoC" and "available to commodity attackers" has collapsed from months to hours.
Pre-positioning. Sophisticated threat groups (particularly ransomware operators and state-sponsored groups) do not wait for public disclosure to begin target selection. They monitor the same vulnerability research channels that defenders do. Some maintain their own vulnerability research capabilities. When a vulnerability is disclosed, they may already have a target list and an exploitation plan. The public disclosure is not the starting gun; it is the signal to execute a plan that was already in motion.
What This Means for Vulnerability Management
The traditional vulnerability management cycle , discover, assess, prioritize, remediate, verify , was designed as a sequential process with human decision-making at each stage. At a time-to-exploitation of weeks, this was workable. At a time-to-exploitation of hours, it is not.
The math is simple. If your change advisory board meets weekly, and the time from disclosure to mass exploitation is 24 hours, then you will be exploited before the CAB meeting where patching is discussed. If your asset inventory is updated quarterly, you may not know which systems are affected until weeks after the exploitation wave has passed. If your patch validation process requires staging deployment and manual testing, the latency of validation exceeds the exploitation window.
This does not mean that patching is irrelevant. It means that patching alone is insufficient for internet-facing systems exposed to critical vulnerabilities. The operational model must include:
Pre-patch exposure assessment. Within hours of a critical CVE disclosure, the security team needs answers to three questions: Do we run this software? Is it internet-reachable? Is the vulnerable code path enabled? These answers require an accurate asset inventory (which most organizations lack), a configuration management database that includes software versions (which most organizations maintain poorly), and network topology awareness (which is often stale). The organizations that answer these questions quickly are the ones with automated asset discovery running continuously, not the ones who run an inventory scan after the advisory drops.
Compensating controls before patching. When patching takes days and exploitation takes hours, the gap must be filled with non-patch mitigations. WAF rules that block known exploit patterns (accepting that these are bypassable but slow down commodity attackers). Network segmentation that limits what a compromised system can reach. Feature flags or configuration changes that disable the vulnerable functionality. These are not substitutes for patching. They are time-buying measures that reduce the window of exploitability while the patch is validated and deployed.
Exposure-based prioritization. CVSS scores are notoriously poor predictors of actual exploitation. A CVSS 9.8 vulnerability in software you do not use is irrelevant. A CVSS 7.5 vulnerability in your internet-facing authentication stack is critical. The prioritization should be based on the product of exploitability (is a PoC available? is mass scanning observed?), reachability (is the vulnerable service internet-facing?), and business impact (what does the system protect or enable?). EPSS (Exploit Prediction Scoring System) is a step in the right direction, but it remains a population-level predictor, not an organization-specific risk assessment.
The Honest Conclusion
The vulnerability management industry has spent two decades optimizing a process , patch management , that is structurally unable to keep pace with the current exploitation timeline for critical vulnerabilities. This is not a failure of execution. It is a failure of the model itself.
The organizations that consistently avoid being in the initial exploitation wave share a few characteristics, and none of them is "we patch faster than everyone else." They minimize their internet-facing attack surface aggressively. They deploy defense-in-depth so that a single unpatched vulnerability does not directly lead to full compromise. They maintain accurate, automated asset inventories so they can assess exposure within hours. They have pre-planned compensating control playbooks for different vulnerability categories (auth bypass, RCE, SSRF). And they assume that every internet-facing system will eventually be targeted by a zero-day or fast-follow exploit, and they design their architecture so that the blast radius of a single compromised system is bounded.
The race between disclosure and exploitation is one that defenders, operating within the constraints of change management and risk assessment, will continue to lose on a per-vulnerability basis. The strategic response is not to run faster in a race you cannot win. It is to design systems where losing the race on any individual vulnerability does not result in catastrophic compromise.
