In well-documented public cases involving critical RCE vulnerabilities, attacks in the wild started within ten to fifteen minutes after the first public proof-of-concept appeared. Not within a day or even hours, but within minutes. The fastest attacks begin before most organizations finish reading the advisory, triage affected systems, or deploy a patch.
This pattern is not new. For years, the security industry has tracked the narrowing gap between CVE disclosure and exploitation. Less attention goes to what that means for AppSec programs centered mainly on patching speed: even highly efficient patch cycles cannot protect against the fastest exploit campaigns because those programs are structurally too slow.
How Rapid Exploitation Unfolds
To understand why exploitation begins within minutes, you need to understand modern threat actor infrastructure. The sequence is roughly:
- Automated CVE monitoring: Threat actor tooling monitors NVD, GitHub, security disclosure lists, and social media for new CVE disclosures and associated PoC publications, typically with alerts triggering within seconds of publication.
- Rapid PoC adaptation: For vulnerabilities in widely-deployed software (Spring framework, Apache servers, common Java/Python libraries), the attacker has existing exploitation frameworks that need only minor adaptation for a new CVE. This adaptation, for some vulnerability classes, now takes under an hour.
- Mass scanner deployment: Botnets and cloud-hosted scanning infrastructure begin probing the internet for vulnerable instances. A Shodan-indexed search for version strings takes seconds to execute. The scan itself, against millions of IPs, begins within minutes of the exploit being ready.
- Automated exploitation: Once a vulnerable instance is identified, exploitation can proceed automatically for many vulnerability classes. Human review is required only for high-value targets or more complex exploitation chains.
As a result, the time from "CVE published with PoC" to "exploitation attempt against your specific systems" is no longer counted in days. For widely deployed software that can be exploited remotely, the first wave arrives within hours, while sustained campaigns unfold over days.
Patching Reality
A responsible patch cycle for production systems in a regulated or high-uptime environment typically looks something like this: vulnerability identified in CI scan or via CVE advisory, ticket created, impact assessed, patch available (may be same-day for some vendors, may be days or weeks for others), patch tested in staging (one to three days), change window scheduled (next Tuesday for many organizations), patch deployed.
Even an exceptionally fast organization realistically needs 24 to 72 hours from CVE publication to patched production deployment, assuming a patch is immediately available. Where change management takes longer, that window stretches to one to four weeks.
The interval between "exploitation begins within minutes" and "patch deploys in 24 to 72 hours at best" is when you remain exposed to active exploitation of a known, unpatched vulnerability. For high-profile CVEs with high exploitability scores, this is not a hypothetical period. It is when the breach occurs.
The First 24 Hours
Public incident reports and honeypot data reveal the typical exploitation timeline for a critical RCE vulnerability in widely deployed software:
- 0-10 minutes: First automated probes for vulnerable version strings begin in some cases, even before PoC is public, based on news of the advisory alone.
- 10-60 minutes: PoC published or independently recreated. Automated exploitation tools updated or built. Mass scanning begins against known IP ranges for affected software.
- 1-6 hours: First wave of opportunistic exploitation against unpatched systems that are internet-accessible. Payloads are typically automated post-exploitation (web shells, coin miners, reconnaissance scripts).
- 6-72 hours: Targeted exploitation of higher-value systems identified during initial scanning. More sophisticated post-exploitation. Persistence mechanisms installed.
An organization that begins patching at hour 2 (very fast) is already in the exploitation window for the most critical internet-accessible systems.
Finding Exploitation Before Patching Is Possible
If the patching process guarantees exposure for a period, the related question is whether you know when exploitation is occurring during that period.
This is where runtime detection changes the equation. An active attempt to exploit a Java deserialization CVE, an SSRF through a vulnerable dependency, or command injection through an unpatched parameter-handling function creates observable syscall patterns. Vulnerable code runs, launches child processes it should not, and opens connections to external hosts outside its normal behavior profile. The attacker's code runs within the application process and interacts with the kernel.
eBPF instrumentation at the syscall boundary identifies the exploitation event, not the vulnerability. That differs from detecting "this CVE exists in your dependency tree," which is what SCA does, or "this request looks malicious," which is what a WAF does. It identifies that "this vulnerable code was just triggered and did something anomalous." Detection occurs in real time during exploitation, before the attacker completes post-exploitation objectives.
Practical Scenario
Consider a Spring Framework RCE-class vulnerability, analogous to Spring4Shell class issues, without attributing it to any specific CVE. An affected organization follows this timeline:
- CVE published at 09:00
- Exploitation attempts against their public API begin at 09:47 (scanning identified their version string)
- Patch available from the framework vendor at 11:30
- Patch deployed to production at 17:00 (fast internal process)
Without runtime detection, the organization is exposed from 09:47 to 17:00, or 7+ hours, without knowing whether exploitation succeeded. A forensic review may find evidence, depending on whether the attacker's actions touched the filesystem.
With eBPF runtime detection, the attempt at 09:47 triggers an alert when the vulnerable code path runs and launches an unexpected child process or makes an unexpected outbound connection. The security team knows at 09:47 that an active attack is underway, can quickly identify affected systems, and can decide whether to take those services offline while expediting the patch. The 7-hour blind period becomes a confirmed exploit event with complete process context, handled as an active incident rather than found after a breach.
Patching Remains the Right Answer
Nothing here argues against patching. Runtime detection addresses the period before the patch is deployed. After deployment, it also helps confirm the patch worked: if the attack pattern no longer activates the vulnerable code path, you have evidence that remediation is complete, not merely that the CVE was closed.
Runtime detection adds something patching alone cannot: real-time confirmation of whether an unpatched vulnerability is under active attack. That knowledge changes the response. Rather than finding a breach weeks later during an audit, you learn about it as it occurs. That is the window AppSec programs cannot afford to leave unmonitored.