And patching faster won't solve it.

‍
In April 2026, cybersecurity researchers published the MOAK results. Mother of All Cves. An autonomous AI workflow that can exploit critical vulnerabilities in under an hour. React Shell: 21 minutes. Without human intervention. Without any prior knowledge of the target.

Ten years ago, the average time between the discovery of a CVE and its active exploitation was 771 days. Today is a matter of minutes.

For the CISO or the CIO who arbitrates priorities, as well as for the teams who manage vulnerabilities on a daily basis, SOC, VOC, IT ops, this figure changes the calculation. Patch management as we know it no longer holds up.

The 30/14/7 cycle is a memory

Patch management policies are based on an implicit assumption: exploitation takes time. Analyze the CVE, develop the exploit, test it, deploy it. Weeks, sometimes months. Enough time to patch before being targeted. 30 days to fix a critical vulnerability. 14 days for exposed systems. 7 days for the most severe cases.

This hypothesis is obsolete.

AI automates operation as soon as a CVE is published. Any group of attackers, not just nation states, can scan the internet and exploit vulnerable systems within minutes of publication. The “spray and pray ofone-days” has become the default strategy: exploit CVEs at the exit, spread the exploits on a large scale.

It is no longer a theoretical threat. This is what MOAK has publicly demonstrated.

The wrong answer: patch faster

The knee-jerk reaction is to reduce deadlines.
30 days become 7. 7 days become 24 hours.

It's a dead end.

The majority of companies manage dozens of interdependent systems, internal validation cycles, and cumbersome CICDs. Deploying a patch in a few hours is not a realistic option at scale. And even organizations that succeed are playing a race they can't win: the operating window will always be shorter than the patch cycle.

In recent years, big businesses have institutionalized this race by creating VOCs, Vulnerability Operations Centers. Dedicated teams, tools, processes, to patch faster than CVEs are exploited.

It is a serious response to a real problem. But it is based on the same broken hypothesis: that time is still on the defender's side.

The VOC is not dead. But his role is about to change. Urgently patching directly exposed systems can no longer be the core of the strategy. The priority must shift: to reduce what is exposed, not to speed up the correction of what is too exposed.

The problem is not speed. It's the architecture.

The real problem: an unnecessarily large attack surface

The right question is not “how do I patch faster?” “She's 'why is this surface exposed in the first place? '

In the vast majority of organizations, web architecture has been based on the same model for 20 years. A browser (standard or not) on the user's computer. A VPN for remote access. Internal applications exposed on the internet, for convenience, for internal users, service providers and third parties.

Some organizations have invested in VDI infrastructures to keep the threat at bay. But VDI doesn't solve the problem : the browser remains exposed, the application as well. And since everything runs in your data centers, an attacker who compromises the infrastructure can bounce laterally on other applications, other systems. If the infrastructure is compromised, the attacker is already in your home.

This model assumes that the threat can be kept at bay by updating and segmenting. MOAK has just shown that this principle no longer holds.

Two concrete examples.

The navigator as a gateway. Each employee who browses the Internet from their workstation exposes a machine connected to the IS. In 2025, Chrome fixed 8 zero-days that were actively exploited in real conditions. The browser has become one of the first entry surfaces in information systems: phishing, drive-by download, CVE exploitation. 55% of cyberattacks pass through this vector according to the CESIN 2025 Barometer. The attacker does not need to look far.

The web application exposed unnecessarily. Thousands of internal applications are accessible from the Internet for remote employees or service providers. We think we are presenting a simple connection interface. In reality, the surface is much larger: APIs, configurations, backend services, databases accessible through configuration errors. The real surface is often ten times that imagined.

In both cases, exposure is not inevitable. It is an architectural choice.

The right answer: reduce the area to the strict minimum

What the attacker cannot achieve, he cannot exploit.

The approach is not to patch faster. It is to build an architecture where the exposed surface is reduced to the minimum necessary.

Two concrete levers:

Browser isolation: If the browsing session takes place in an isolated environment, physically disconnected from the computer and the IS, the zero-day browser never reaches the user's machine. The stream received on the computer is a simple video stream. No executable web code. Whether the CVE exists on the user computer, whether it is known, unknown or not patched: it never reaches the computer. No exploit possible.

Web application isolation: If the user or the service provider accesses the application via an isolated browser, the application is no longer in direct contact with an uncontrolled computer. It is no longer exposed on the internet. The area visible to the attacker is reduced to a minimum.

What does that actually change

The question “Have you patched your browsers?” becomes secondary when the browsing session is physically removed from the user computer.

The question “Is your application accessible from the internet?” disappears when access is through an insulation layer.

It's not a one-size-fits-all answer. Web browsing isolation does not cover the entire attack surface of an organization. But on the web vector, no patch will ever be deployed as quickly as a CVE will be exploited. The only answer that holds up: make the target untouchable. Not a filter, not a local isolation like a Enterprise Browser where an attacker could escape and move laterally. The session runs on a remote server, far from the computer, far from the IS. The attacker reaches a disposable environment. Nothing else.

In summary

MOAK proved that 21 minutes are enough to operate a critical CVE. The answer cannot be “patch in 20 minutes.” It is “to ensure that the CVE does not find a surface to exploit”.

Patch management is still necessary. But it can no longer be the only line of defense on the web vector.

If your web security strategy is still based on reactivity, detecting, prioritizing, patching, MOAK has just shown that this posture has an expiration date. The question is no longer “when to patch?” She is “what should not be exposed in the first place?”

VirtualBrowser physically isolates web browsing sessions. No code reaches the computer, no application is exposed on the Internet. Deployed to 100+ organizations, including classified defense environments. 150,000 active users.

‍