The Patch Gap: Attackers Move Faster Than Patches

Vikram is the IT head at a logistics company in Hyderabad. Every Monday morning he runs a patch review. His team identifies critical vulnerabilities from the previous week, tests the patches, schedules a maintenance window, and deploys. It is disciplined. It is documented. His leadership team is happy with the process.

The problem is that Monday morning is too late. In most cases, by the time Vikram's patch cycle begins, attackers have already been inside vulnerable systems for four to six days.

This is not Vikram's failure. It is a fundamental shift in how cyberattacks work — and most organisations have not yet understood what it means for them.

The Old Assumption That No Longer Holds

For decades, the security industry operated on a reasonable assumption: vulnerabilities are discovered, vendors build patches, organisations deploy them, and the window of risk is manageable. Patch within 30 days of a critical vulnerability and you are largely safe. Patch within 7 days and you are doing very well.

That assumption is now broken.

In April 2026 alone — in less than one week — we have seen:

• Chrome CVE-2026-5281 (WebGPU zero-day) — actively exploited before the patch was even announced
• FortiClient EMS CVE-2026-21643 — exploited for four full days before appearing on any official tracking list
• FortiClient EMS CVE-2026-35616 — a new critical flaw found inside the patch that fixed the previous one
• Langflow CVE-2026-33017 — attackers built a working exploit within 20 hours of the advisory being published
• Drift Protocol — $285 million stolen in 10 seconds after six months of preparation

These are not separate incidents. They are data points in a single pattern: the time between vulnerability disclosure and active exploitation has collapsed to hours — sometimes less.

How Fast Is Fast? The Numbers

Google's Project Zero team tracks how quickly vulnerabilities move from disclosure to exploitation. Their data from 2025 showed that the median time-to-exploit for critical vulnerabilities had dropped to 11 days. In early 2026, their updated analysis shows it has dropped further — to under 5 days for high-profile targets.

For the most critical flaws — the ones rated 9.0 or above on the CVSS scale — the window is even shorter. Langflow was exploited in 20 hours. The FortiClient flaw was exploited within 96 hours. Chrome's WebGPU zero-day was being used before the patch existed at all — meaning the exploitation window was technically infinite before defenders could act.

A weekly patch cycle assumes you have seven days to respond. The data from April 2026 shows the real window is closer to 24 hours — for the vulnerabilities that matter most. Organisations running weekly cycles are structurally five to six days behind every serious attack.

Three Reasons the Race Is Getting Harder to Win

1. AI is accelerating vulnerability discovery on both sides

Security researchers now use AI tools to analyse patches the moment they are released. The process works like this: a vendor releases a patch; the researcher feeds the patch into an AI model and asks it to identify what changed and why; the model can often identify the exact vulnerable code path within minutes. What used to take a skilled researcher days now takes hours.

Attackers use the same tools. The moment Microsoft, Google, or Fortinet releases a patch, criminal groups and state-sponsored teams run the same analysis. The patch itself becomes the roadmap to the vulnerability.

We are seeing this pattern clearly in 2026. The Langflow advisory was detailed and technically precise. Attackers read it, understood it, and built a working exploit in 20 hours. The researcher who found it said it was "extremely easy" — not because the flaw was simple, but because the advisory explained it so completely.

2. Patch quality is declining under speed pressure

Vendors are under pressure to patch faster than ever. The result is that patches are increasingly incomplete. We covered two clear examples this month alone.

FortiClient EMS CVE-2026-21643 was patched in version 7.4.5. Version 7.4.5 contained CVE-2026-35616 — a new critical vulnerability introduced by the fix. Organisations that patched promptly found themselves vulnerable to a different critical flaw in the version they had just upgraded to.

Chrome CVE-2026-5281 was described in Google's own advisory as an incomplete fix of a prior vulnerability. The original flaw was patched. A related code path was missed. Attackers found the missed path.

This creates a cruel dilemma: patch slowly and you are vulnerable to the known flaw. Patch immediately and you may be vulnerable to a new flaw introduced by the rushed fix. The only answer is to patch immediately and then monitor for the next patch — but most organisations are not resourced to do this continuously.

3. Internet-facing systems are being scanned in real time

In 2026, the entire internet is continuously scanned by automated tools — both legitimate security research scanners and attacker infrastructure. Within minutes of a new vulnerability being published, automated systems begin probing every internet-facing server on the planet looking for vulnerable versions.

Shadowserver — a non-profit that tracks internet-exposed vulnerable systems — reported that within 24 hours of the FortiClient EMS CVE-2026-21643 advisory, over 2,000 vulnerable servers had been identified and were actively being probed. These were not targeted attacks. They were automated sweeps finding every unlocked door simultaneously.

If your server is on the internet and it is running a critical vulnerability, attackers will find it. The question is only how fast.

What Most Organisations Are Missing

The standard security advice — patch regularly, keep systems updated, follow a vulnerability management process — is correct but insufficient. It assumes that a well-managed patch cycle is enough to stay ahead of attackers. In 2026, it is not.

The missing insight is this: patching is reactive by definition. Attacks are proactive by design.

An attacker chooses when to strike. They choose which vulnerability to use. They choose the moment of maximum impact — on a Friday night, on a holiday weekend, in the first hours after a patch is released when most organisations have not yet deployed it. The defender has no choice about when the attack comes. They can only choose how prepared they are when it arrives.

The organisations that are surviving this shift are not necessarily patching faster than everyone else. They are reducing the attack surface so that being a few days behind on a patch does not mean catastrophic exposure.

What Actually Works in 2026

Remove internet exposure for anything you do not absolutely need online. This is the single highest-impact action available to most organisations. FortiClient EMS had over 2,000 instances directly reachable from the internet. There is almost no legitimate reason for an endpoint management server to be publicly accessible. Take it off the internet and the entire class of unauthenticated remote exploits becomes irrelevant — attackers cannot reach what they cannot see.

Treat CVSS 9.0+ vulnerabilities as same-day patches, not scheduled ones. Reserve your weekly patch cycle for medium and low severity issues. Critical vulnerabilities — anything rated 9.0 or above — need to be assessed within hours of disclosure and patched within 24 to 48 hours. This requires a clear escalation process agreed in advance, not improvised after the advisory drops.

Subscribe directly to vendor advisories, not just government lists. CISA's Known Exploited Vulnerabilities list is valuable — but it is reactive. CVE-2026-21643 was exploited for four days before appearing on any official list. Fortinet's PSIRT feed, Google's security blog, and Microsoft's Security Response Center publish advisories before exploitation is confirmed. Subscribe to the source, not the summary.

Monitor for exploitation signals, not just patch status. Your patch management dashboard tells you which systems are up to date. It does not tell you whether a system was compromised in the window before the patch was deployed. Continuous monitoring for exploitation indicators — unusual process activity, unexpected outbound connections, abnormal authentication patterns — is what catches the attacks that happened before the patch arrived.

Assume a breach window exists for every critical vulnerability. Between the moment a vulnerability is disclosed and the moment your patch is fully deployed and verified, there is a window. For most organisations, that window is measured in days. Operate on the assumption that during that window, a sophisticated attacker may have attempted or succeeded in exploitation. This shifts your posture from "patch and done" to "patch and investigate."

The ZyberWalls Perspective

Every major attack we have covered this month followed the same underlying logic. Langflow exploited in 20 hours. FortiClient EMS exploited before the patch appeared on official lists. Chrome hit with a zero-day before a patch existed. The Drift Protocol attack planned for six months, executed in 10 seconds — because the attackers controlled the timing completely while the defenders had no idea the clock was running.

Speed is no longer just an operational concern. It is the defining characteristic of the modern threat landscape. The organisations that understand this are already changing how they work — moving from scheduled maintenance windows to continuous assessment, from compliance-driven patching to risk-driven prioritisation, from "are we patched?" to "were we exposed before we patched?"

The organisations that have not yet understood this are running Vikram's Monday morning patch review — disciplined, documented, and five days too late.

The race is real. The gap is measurable. And it is widening.

→ Chrome CVE-2026-5281: You Visited a Webpage. That Was Enough.

→ The Patch That Wasn't Safe: FortiClient EMS Hit by Two Critical Zero-Days

→ Langflow CVE-2026-33017: Exploited in 20 Hours