The Vanishing Patch Window: Time-to-Exploitation in Mid-2026 KEV Additions

Nine CVEs, Two Weeks, No Grace Period

Between July 1 and July 14, 2026, CISA added nine unrelated CVEs to the Known Exploited Vulnerabilities catalog — spanning a perimeter appliance vendor (SonicWall), an enterprise application platform (Adobe ColdFusion), four Joomla extensions, an AI workflow tool (Langflow), and two Microsoft identity/collaboration products (AD FS, SharePoint). None of these products share a codebase, a vendor, or a disclosure process. What they share is a timeline, and the timeline is the story.

Six of nine had no meaningful gap at all — attackers were already inside the window, or arrived within hours. Two gave defenders something resembling a traditional patch cycle, and even those were measured in weeks, not months. This is not a cherry-picked set of dramatic outliers; it is every CVE CISA confirmed as actively exploited in a single fortnight.

What "Zero-Day" Actually Means Here

Three distinct mechanisms produced a zero (or negative) gap in this dataset, and the distinction matters for what defenders can do about each:

Attackers found it before the vendor did. CVE-2026-56155 (AD FS) and CVE-2026-56164 (SharePoint) were both credited to incident-response teams — Microsoft's own DART unit, and Mandiant/Google FLARE, respectively — not to proactive security researchers. That attribution pattern is itself the signal: these vulnerabilities were discovered because someone was already investigating a live intrusion. By the time Microsoft shipped a July Patch Tuesday fix, the attackers had a head start measured in an unknown number of weeks or months of undetected access.

A researcher's disclosure window collided with an attacker's scan. CVE-2026-48939 (iCagenda) and CVE-2026-56291 (Balbooa Forms) both follow the same shape: a security researcher (mySites.guru, in both cases) was alerted to live exploitation by a client's access logs, traced the request to a vulnerable code path, and disclosed to the vendor the same day or the next. The vendor shipped a fix within 24 hours. Attackers were exploiting the flaw before the patch existed in both cases — the "responsible disclosure" window that classic patch-management guidance assumes simply didn't exist.

Automated exploitation infrastructure was already primed. CVE-2026-48282 (Adobe ColdFusion) is the cleanest example of pure speed: KEVIntel's honeypot network recorded the first exploitation attempt roughly two hours after Adobe's advisory went live. That is not a targeted actor reading the bulletin and crafting an exploit — it is infrastructure that was already watching for the advisory and had a generic exploitation technique (RDS FILEIO path traversal) ready to fire the moment a specific target CVE number appeared.

The Two Outliers Are the Interesting Part

CVE-2026-48908 (JoomShaper SP Page Builder) and CVE-2026-55255 (Langflow) are the exceptions in this dataset, and they're informative exactly because they're exceptions.

JoomShaper's fix shipped June 14; CISA didn't add the CVE to KEV until July 7, roughly three weeks later. That gap doesn't mean attackers waited three weeks to start — mySites.guru's research (which also covers CVE-2026-56290 and CVE-2026-56291 in this same window) shows the same file-upload vulnerability class being actively exploited across multiple Joomla extensions on a much faster timeline. It more likely means detection and confirmation lagged: a niche Joomla page-builder extension does not have a honeypot network watching it the way Adobe ColdFusion or a Microsoft product does. The exploitation was probably close to immediate; the visibility into that exploitation was not.

Langflow is the more striking case. The fix landed April 22. Sysdig didn't observe the first known exploitation until June 25 — a 64-day gap that is an order of magnitude longer than everything else in this dataset, on a CVSS 8.4 vulnerability in a category (AI agent orchestration platforms) that is growing fast and attracting real attention. The likely explanation isn't that the bug was hard to find or hard to exploit — Sysdig's own write-up describes a straightforward two-step attack (enumerate flow IDs, replay one you don't own). It's that Langflow, in April 2026, wasn't yet a large enough target population to be worth an opportunistic scanner's time. That population is changing quickly; see our companion piece on agentic AI platform security for what changed between April and June.

Read together, the two outliers suggest the "grace period" hasn't disappeared uniformly — it has concentrated. High-visibility, widely deployed, internet-facing software (VPN appliances, enterprise CMS platforms, Microsoft's identity and collaboration stack) now gets effectively zero grace period, because the scanning and honeypot infrastructure watching those targets is mature. Lower-visibility software still gets a longer runway, but that runway is measured in weeks, not the months or years it used to buy — and it closes the moment the software's install base or attack surface starts attracting attention.

This Is a Change From the Last Era, Not a Continuation of It

Our Landmark CVEs piece documents the previous shift: Log4Shell (2021) and Apache ActiveMQ (2023) normalized 24-hour exploitation windows, a number that felt alarmingly fast at the time. Atlassian Confluence's OGNL injection flaw was already being exploited as a zero-day before its patch existed in 2022, and Cl0p's MOVEit campaign in 2023 had no patch-to-exploit gap at all. Even then, though, those cases were the sharp end of the distribution — Citrix ADC sat unpatched and under mass exploitation for six weeks in 2019/2020, and WannaCry's EternalBlue gap was measured in two months.

Two years later, the sharp end has become the median. Of the nine CVEs examined here, the 24-hour benchmark that Log4Shell set as an extreme case in 2021 would be the second-slowest result in this entire dataset. Six had no gap to speak of. The distribution hasn't just shifted faster — its shape has changed, from a long tail of slow-moving exploitation with occasional zero-day outliers, to a cluster at zero with a short tail of weeks-long delays reserved for whatever hasn't yet attracted scanner attention.

Why "Patch on Disclosure Day" No Longer Works

The traditional vulnerability management pitch — subscribe to advisories, patch within your SLA, you're covered — assumes the SLA clock and the attacker's clock start at the same moment. That assumption is the part that's broken. In six of the nine cases here, the attacker's clock had already been running before the defender's clock started, or was running in parallel infrastructure primed to fire the instant a patch (and therefore a target) became public.

That has three concrete implications:

Patching on disclosure day is a response to an assumed-compromised state, not a preventive measure, for a growing share of vulnerability classes. If your ColdFusion, SonicWall, or SharePoint instance was internet-facing and unpatched when these advisories dropped, the honest operating assumption is that it was probed or compromised before you finished reading the bulletin — not that patching promptly kept you safe. Incident response and compromise assessment need to run in parallel with patching, not after it, for any CVE in this pattern.

Leading indicators beat official disclosure. KEVIntel's honeypot network caught ColdFusion exploitation roughly a week before CISA's KEV addition. mySites.guru caught iCagenda and Balbooa Forms exploitation via client access logs before any public advisory existed at all. Threat intelligence feeds, honeypot networks, and researcher disclosure channels are now running ahead of the mechanisms (vendor bulletins, KEV additions) that most patch-management programs are built around. An organization whose vulnerability management process only triggers on KEV additions or vendor CVSS scores is, for this class of vulnerability, reading yesterday's news.

Visibility gaps are becoming the new grace period — and they're shrinking. The two slower cases in this dataset weren't slow because the vulnerabilities were harder to exploit; they were slow because detection lagged behind exploitation. That gap is not a stable safety margin. It closes as soon as a piece of software's footprint grows large enough to attract the same automated attention that ColdFusion and SonicWall already have. Betting on obscurity as a substitute for patch speed is a bet against your own product's success.

What This Changes in Practice

1. Stop measuring patch programs against "time to patch after disclosure" alone. For internet-facing perimeter and identity infrastructure specifically, add "time to detection of anomalous activity" as an equally weighted metric — because the patch, in a growing share of cases, arrives after the compromise, not before it.
2. Treat every advisory for internet-facing software as a compromise-assessment trigger, not just a patch ticket. Pull logs for the affected system covering the weeks before the advisory, not just the hours after. Several of the CVEs here were exploited well before public disclosure; your window of concern needs to extend backward, not just forward.
3. Subscribe to threat-intel and honeypot telemetry, not just vendor bulletins and KEV RSS feeds. KEVIntel, Shadowserver, and researcher blogs (mySites.guru, Sysdig, and similar) are consistently surfacing exploitation before it reaches an official advisory or KEV addition. Build that into your alerting, not just your reading list.
4. Don't let low visibility lull you into a longer patch SLA for niche software. The JoomShaper and Langflow cases show that lower-profile products still get a longer runway today — but that runway is a function of attacker attention, not inherent safety, and it can close as fast as a product's install base grows.
5. Assume perimeter and identity infrastructure (VPN gateways, ADFS, SharePoint, CMS platforms) will be probed within hours of any future advisory. Pre-stage incident response playbooks, isolate management interfaces from the internet by default, and design so that a single unpatched instance isn't a single point of total compromise.

The organizations that came through this fortnight cleanly were not, in most cases, the ones that patched fastest after disclosure — the data here shows disclosure-day patching would have been too late for two-thirds of these CVEs regardless. They were the ones whose exposure was already minimized, whose monitoring caught the anomaly independent of any advisory, or whose management interfaces were never reachable from the internet in the first place. The patch window hasn't just shrunk. For a majority of the vulnerabilities that matter most, it's already gone by the time you hear about it.