En avril 2026, des chercheurs en cybersécurité ont publié les résultats de MOAK. Mother of All CVEs. Un workflowd 'IA autonome capable d'exploiter des vulnérabilités critiques en moins d'une heure. React Shell : 21 minutes. Sans intervention humaine. Sans aucune connaissance préalable de la cible.

Il y a dix ans, le délai moyen entre la découverte d'une CVE et son exploitation active était de 771 jours. Aujourd'hui, c'est une question de minutes.

Pour le RSSI ou le DSI qui arbitre les priorités, comme pour les équipes qui gèrent les vulnérabilités au quotidien, SOC, VOC, IT ops, ce chiffre change le calcul. Le patch management tel qu'on le connaît ne tient plus.

Le cycle 30/14/7 est un souvenir

Les politiques de patch management reposent sur une hypothèse implicite : l'exploitation prend du temps. Analyser la CVE, développer l'exploit, le tester, le déployer. Des semaines, parfois des mois. Assez de temps pour patcher avant d'être ciblé. 30 jours pour corriger une vulnérabilité critique. 14 jours pour les systèmesexposés. 7 jours pour les cas les plus sévères.

Cette hypothèse est caduque.

L'IA automatise l'exploitation dès la publication d'une CVE. N'importe quel groupe d'attaquants, pas seulement les États-nations, peut scanner l'internet et exploiter les systèmes vulnérables dans les minutes suivant la publication. Le "spray and pray ofone-days" est devenu la stratégie par défaut : exploiter les CVEs à la sortie, répandre les exploits à grande échelle.

Ce n'est plus une menace théorique. C'est ce que MOAK a démontré publiquement.

La mauvaise réponse : patcher plus vite

La réaction instinctive est de réduire les délais.
30 jours deviennent 7. 7 jours deviennent 24 heures.

C'est une impasse.

La majorité des entreprises gère des dizaines de systèmes interdépendants, des cycles de validation internes, des CICDs lourds. Déployer un patch en quelques heures n'est pas une option réaliste à l'échelle. Et même les organisations qui y parviennent jouent une course qu'elles ne peuvent pas gagner : la fenêtre d'exploitation sera toujours plus courte que le cycle de patch.

Ces dernières années, les grandes entreprises ont institutionnalisé cette course en créant des VOC, Vulnerability Operations Centers. Des équipes dédiées, des outils, des processus, pour patcher plus vite que les CVEs ne sont exploitées.

C'est une réponse sérieuse à un problème réel. Mais elle repose sur la même hypothèse cassée : que le temps joue encore en faveur du défenseur.

Le VOC n'est pas mort. Mais son rôle va changer. Patcher en urgence des systèmes directement exposés ne peut plus être le coeur de la stratégie. La priorité doit se déplacer : réduire ce qui est exposé, pas accélérer la correction de ce qui l'est trop.

Le problème n'est pas lavitesse. C'est l'architecture.

Le vrai problème : une surface d'attaque inutilement large

La bonne question n'est pas "comment patcher plus vite ?" Elle est "pourquoi cette surfaceest-elle exposée en premier lieu ?"

Dans la grande majorité des organisations, l'architecture web repose sur le même modèle depuis 20 ans. Un navigateur (standard ou non) sur le poste de l'utilisateur. Un VPN pour les accès distants. Des applications internes exposées sur internet, par commodité, pour les internes, prestataires et les tiers.

Certaines organisations ont investi dans des infrastructures VDI pour maintenir la menace à distance. Mais le VDI ne résout pas le problème : le navigateur reste exposé, l'application également. Et comme tout tourne dans vos datacenters, un attaquant quicompromet l'infrastructure peut rebondir latéralement sur d'autres applications, d'autres systèmes. Si l'infrastructure est compromise, l'attaquant est déjà chez vous.

Ce modèle part du principe que la menace peut être tenue à distance par la mise à jour et la segmentation. MOAK vient de montrer que ce principe ne tient plus.

Deux exemples concrets.

Le navigateur comme porte d'entrée. Chaque collaborateur qui navigue sur internet depuis son poste de travail expose une machine connectée au SI. En 2025, Chrome a corrigé 8 zero-days activement exploités en conditions réelles. Le navigateur est devenu l'une des premières surfaces d'entrée dans les systèmes d'information : phishing, drive-by download, exploitation de CVE. 55% des cyberattaques passent par ce vecteur selon le Baromètre CESIN 2025. L'attaquant n'a pas besoin dechercher loin.

L'application web exposée inutilement. Des milliers d'applications internes sont accessibles depuis internet pour les collaborateurs en télétravail ou les prestataires. On croit exposer une simple interface de connexion. En réalité, la surface est bien pluslarge : APIs, configurations, services backend, bases de données accessibles via des erreurs de configuration. La surface réelle est souvent dix fois celle imaginée.

Dans les deux cas, l'exposition n'est pas une fatalité. C'est un choix d'architecture.

La bonne réponse : réduire la surface au strict minimum

Ce que l'attaquant ne peut pas atteindre, il ne peut pas exploiter.

L'approche n'est pas de patcher plus vite. C'est de construire une architecture où la surface exposée estréduite au minimum nécessaire.

Deux leviers concrets :

Isolation du navigateur : Si la session de navigation se déroule dans un environnement isolé, physiquementdéconnecté du poste et du SI, le zero-day navigateur n'atteint jamais la machine de l'utilisateur. Le flux reçu sur le poste est un simple stream vidéo.Pas de code web exécutable. Que la CVE existe sur le poste utilisateur, qu'elle soit connue, inconnue ou non patchée : elle n'atteint jamais le poste. Aucun exploit possible.

Isolation de l'application Web : Si l'utilisateur ou le prestataire accède à l'application via unnavigateur isolé, l'application n'est plus en contact direct avec un poste nonmaîtrisé. Elle n'est plus exposée sur internet. La surface visible par l'attaquant se réduit au minimum.

Ce que ça change concrètement

La question "Avez-vous patché vos navigateurs ?" devient secondaire quand la session denavigation est physiquement déportée du poste utilisateur.

La question "Votre application est-il accessible depuis internet ?" disparaît quand l'accès passe par une couche d'isolation.

Ce n'est pas une réponse universelle. L'isolation de la navigation web ne couvre pas toute la surface d'attaque d'une organisation. Mais sur le vecteur web, aucun patch ne sera jamais déployé aussi vite qu'une CVE sera exploitée. La seule réponse qui tient: rendre la cible intouchable. Pas un filtre, pas une isolation locale comme un Enterprise Browser où un attaquant pourrait s'évader et se déplacer latéralement. La session tourne sur un serveur distant, loin du poste, loin du SI. L'attaquant atteint un environnement jetable. Rien d'autre.

En résumé

MOAK a prouvé que 21 minutes suffisent pour exploiter une CVE critique. La réponse ne peut pas être"patcher en 20 minutes". Elle est "faire en sorte que la CVE ne trouve pas de surface à exploiter".

Le patch management reste nécessaire. Mais il ne peut plus être la seule ligne de défense sur le vecteur web.

Si votre stratégie de sécurité web repose encore sur la réactivité, détecter, prioriser, patcher, MOAK vient de montrer que cette posture a une date d'expiration. La question n'est plus "quand patcher ?" Elle est "qu'est-ce qui ne devrait pas être exposé en premier lieu ?"

VirtualBrowse risole physiquement les sessions de navigation web. Aucun code n'atteint leposte, aucune application n'est exposée sur internet. Déployé chez 100+ organisations, dont des environnements classifiés de défense. 150 000 utilisateurs actifs.

‍