Une entreprise du Bassin Genevois fait tourner une vingtaine de machines virtuelles sur deux hyperviseurs, avec une console d'administration centrale. Personne ne la regarde au quotidien, et c'est normal : elle fonctionne. Le 29 juillet, l'éditeur publie un correctif pour cette console. Le 30, le CERT-FR relaie l'avis. Le 3 août, les premières exploitations sont observées. Le 18 août, l'agence américaine chargée de la cybersécurité inscrit la faille à son catalogue des vulnérabilités activement exploitées. Entre la mise à disposition du correctif et la campagne d'attaque organisée, il s'est écoulé cinq jours.
Cinq jours, ce n'est pas un délai théorique. C'est le temps réel dont dispose une PME pour décider, planifier une fenêtre et appliquer une mise à jour sur un composant qui commande tout son parc virtualisé. La plupart des entreprises que nous auditons n'ont aucun processus capable de tenir ce rythme, non par négligence, mais parce que personne n'a jamais écrit qui décide, en combien de temps et sur quels systèmes.
Ce qui s'est passé cet été sur VMware vCenter
La vulnérabilité porte la référence CVE-2026-59310 et affiche la note maximale ou presque, 9,8 sur 10. Elle réside dans le serveur Syslog de vCenter et repose sur un défaut de traversée de répertoires. Concrètement, une personne disposant simplement d'un accès réseau à la console, sans aucun identifiant, peut exécuter du code sur celle-ci. Le même bulletin de l'éditeur, publié le 29 juillet, corrige une seconde vulnérabilité critique de même gravité, un contournement d'authentification dans l'annuaire interne de vCenter.
L'éditeur a été clair sur un point : il n'existe aucun contournement ni mesure d'atténuation temporaire. La seule réponse est la mise à jour. Les chercheurs qui ont suivi la campagne comptent plusieurs centaines d'adresses réparties dans des dizaines de pays, et la France figure parmi les cinq pays les plus touchés. L'objectif des attaquants, dans les cas documentés, consiste à installer un accès distant persistant sur le cœur de l'infrastructure virtualisée, parfois suivi d'un rançongiciel.
Le correctif ne referme pas une porte déjà posée
C'est le point que les dirigeants comprennent le plus tard, et il change tout dans la conduite d'un incident. Si votre console a été exposée sur le réseau entre le 3 et le jour de votre mise à jour, appliquer le correctif empêche une nouvelle intrusion par ce chemin, mais ne supprime pas un accès qui aurait déjà été installé. La porte d'entrée est bouchée, l'occupant reste à l'intérieur.
La bonne séquence est donc en trois temps, et dans cet ordre : vérifier la version en service, appliquer la mise à jour, puis chercher les traces d'une compromission antérieure au correctif. Cette troisième étape suppose des journaux conservés ailleurs que sur la machine concernée et une idée de ce à quoi ressemble un comportement normal. C'est exactement ce que produit une supervision tenue dans la durée, sujet que nous développons dans notre article sur la supervision d'un parc avec Zabbix.
La même histoire côté Windows, avec quatre mois d'écart
Le même 18 août, une seconde vulnérabilité a rejoint ce catalogue des failles activement exploitées : CVE-2026-33824, qui touche le service de négociation de clés IKE de Windows et permet également une exécution de code à distance sans authentification. Microsoft l'avait corrigée en avril 2026.
Quatre mois séparent donc le correctif de l'exploitation de masse, et pourtant de nombreux systèmes sont restés exposés. Cet écart raconte quelque chose de plus dérangeant que le cas VMware. Il ne s'agit plus d'une course de vitesse contre des attaquants très rapides, mais d'un correctif disponible depuis un trimestre entier et jamais appliqué. Dans les parcs que nous reprenons, la cause est presque toujours la même : les mises à jour de sécurité mensuelles sont appliquées sur les postes de travail, où le mécanisme est automatique, et pas sur les serveurs, où il faut planifier un redémarrage et prévenir les utilisateurs.
Ce qu'une PME peut réellement tenir
Un engagement de délai n'a de valeur que s'il est tenable. Une entreprise de quinze personnes ne peut pas promettre de corriger toute faille en vingt-quatre heures, et personne ne le lui demande. Ce qui est tenable, en revanche, tient en quatre décisions écrites avant l'incident.
- Un inventaire à jour. On ne corrige pas ce qu'on ne sait pas posséder. La liste doit couvrir les hyperviseurs, les serveurs, les équipements réseau et les consoles d'administration, avec pour chacun sa version en service et la personne qui décide de son arrêt.
- Une source d'alerte unique. Un flux officiel, celui du CERT-FR et ceux de vos éditeurs, plutôt que la découverte d'une faille par un courriel commercial. Le tri se fait une fois, en un point, pas dix fois dans dix boîtes de réception.
- Un délai par niveau de criticité. Par exemple, une faille exploitée sur un composant exposé se traite dans la journée, une faille critique non exploitée dans la semaine, le reste au cycle mensuel. Les chiffres exacts vous appartiennent, l'important est qu'ils existent avant d'en avoir besoin.
- Une exception documentée. Un applicatif métier qui interdit la mise à jour d'un serveur n'est pas un incident, c'est un risque accepté par écrit, avec une mesure de compensation et une date de réexamen. Sans cette ligne, l'exception devient permanente et personne ne s'en souvient.
Une console d'administration accessible depuis l'extérieur mérite une mention à part. La règle générale reste de ne jamais exposer une interface d'administration sur internet, principe que nous détaillons dans notre article sur le bureau à distance exposé, et le pare-feu qui applique cette règle ne devrait pas être la box de l'opérateur, sujet abordé dans le pare-feu et la box opérateur.
Comment nous procédons dans un contrat
L'audit d'entrée produit l'inventaire et relève l'écart de version de chaque machine, y compris les équipements que plus personne ne revendique. Nous en sortons une liste priorisée, avec les systèmes qui commandent les autres en tête : hyperviseurs, annuaire, sauvegarde, pare-feu.
Le contrat fixe ensuite les fenêtres de maintenance et les délais par criticité, et nous tenons le journal de ce qui a été appliqué, quand, et sur quoi. C'est ce journal qui permet de répondre en une heure lorsqu'une faille fait la une, plutôt que de passer deux jours à retrouver les versions en service. Le volet technique de ce travail est présenté sur notre page gestion de serveurs, et la partie détection sur notre page cybersécurité. Un contrat d'infogérance démarre à 120 HT / mois, dimensionné après l'audit du parc, et nous nous déplaçons dans tout le Bassin Genevois.
Si vous administrez des hyperviseurs et que vous ne savez pas dire aujourd'hui quelle version ils font tourner, la question n'est pas de savoir si vous êtes vulnérable à cette faille précise. Elle sera remplacée par une autre dans quelques semaines. Demandez-nous un état des lieux : nous vous rendrons l'inventaire, l'écart de version et l'ordre dans lequel traiter.