361 Serveurs vCenter Touchés Avant l'Entrée en KEV

Neuf Jours du Correctif à 361 Victimes

Broadcom a publié l'avis VMSA-2026-0006 le 29 juillet 2026, divulguant CVE-2026-59310 aux côtés d'une faille complémentaire de contournement d'authentification, CVE-2026-59309, dans VMware vCenter Server 8.0, 9.0 et 9.1. Les versions corrigées ont été mises à disposition le jour même : vCenter 9.1.0.0300, vCenter 9.0.2.0100 et vCenter 8.0 U3k ou U2f selon la branche de mise à jour déployée.

QUIRSO GmbH, un cabinet allemand de criminalistique numérique et de réponse aux incidents, indique que l'infrastructure contrôlée par l'attaquant a enregistré ses premières connexions entrantes depuis des systèmes vCenter exploités le 3 août 2026, cinq jours seulement après la sortie du correctif. Au 7 août, le cabinet avait dénombré 361 adresses IP de victimes distinctes réparties dans 47 pays, avec environ la moitié concentrée en Allemagne, aux États-Unis, en Turquie, en Iran et en France. QUIRSO a publié une règle de détection YARA aux côtés de ses conclusions, tout en retenant certains indicateurs de compromission le temps de sa coordination avec les autorités.

Une Fonction Syslog Qui Livre le Serveur Entier

CVE-2026-59310 se situe dans la logique de traitement des répertoires du composant Syslog Server de vCenter. L'avis de Broadcom lui-même indique sans détour qu'un acteur malveillant disposant d'un accès réseau à vCenter peut exploiter le problème pour exécuter du code arbitraire, et, point crucial, sans authentification préalable requise. Cette combinaison, absence d'authentification plus exécution de code au niveau système, est ce qui a valu à la faille son score de gravité de 9,8 sur 10 et ce qui fait de toute instance vCenter accessible depuis internet une cible immédiate plutôt que théorique.

vCenter n'est pas un outil périphérique. C'est le plan de gestion de l'ensemble du parc de virtualisation d'une organisation, la console qui provisionne, migre et contrôle chaque machine virtuelle qu'une entreprise exploite. Un avis d'éditeur pour ce produit précis ne devrait jamais attendre dans la même file qu'un correctif applicatif de routine.

Pourquoi reverse_ssh Contourne la Règle de Pare-feu Déjà en Place

Plutôt que d'ouvrir un port en écoute sur le serveur vCenter compromis, ce que la plupart des systèmes de surveillance réseau sont conçus pour détecter, les attaquants derrière cette campagne installent reverse_ssh, un outil open source en Go qui fait établir à la machine compromise une connexion SSH sortante vers l'infrastructure de l'attaquant. Comme la connexion est sortante, elle peut échapper aux politiques de pare-feu et de réseau configurées pour bloquer le trafic entrant non sollicité mais qui laissent passer des sessions sortantes d'apparence ordinaire, offrant à l'attaquant un point d'ancrage durable et interactif capable de survivre à un simple audit de segmentation réseau.

Pour un appareil déjà au coeur du parc de virtualisation d'une organisation, ce mécanisme de persistance transforme un seul serveur vCenter non corrigé en une tête de pont durable plutôt qu'un coup unique.

Thèse Originale : L'Écart avec la KEV Est la Vraie Histoire Ici

La plupart des analyses de vulnérabilités mesurent l'urgence selon qu'une faille a atterri ou non dans le catalogue Known Exploited Vulnerabilities de la CISA, et de nombreux programmes de correctifs sont bâtis, formellement ou non, autour de ce même déclencheur. CVE-2026-59310 dément cette hypothèse. La télémétrie indépendante de QUIRSO et du cabinet de sécurité Rapid7 a documenté des centaines de compromissions réelles dans 47 pays au cours de la première semaine et demie suivant la divulgation, et pourtant, au moment de la rédaction, la CVE n'était toujours pas apparue dans le catalogue de la CISA. Un flux de correctifs qui traite l'inscription au KEV comme le signal pour faire passer un avis vCenter au statut d'urgence avait donc, par définition, déjà des semaines de retard sur les attaquants qui avaient trouvé et armé cette faille.

La leçon dépasse cette seule CVE. Pour un logiciel de niveau infrastructure comme une console de gestion d'hyperviseur, la télémétrie d'un cabinet d'expertise indépendant ou le score de gravité de l'éditeur lui-même devraient suffire à déclencher un correctif d'urgence, sans attendre une entrée dans un catalogue gouvernemental qui, cette fois, n'est tout simplement pas arrivée à temps.

Ce Que les Exploitants de vCenter Doivent Faire Maintenant

Toute organisation exploitant vCenter 8.0, 9.0 ou 9.1 qui n'a pas encore appliqué les correctifs du 29 juillet devrait traiter cela comme un changement d'urgence, non planifié, et devrait également vérifier que l'interface de gestion n'est pas directement accessible depuis internet public, ce qui ne devrait jamais être le cas en premier lieu. Compte tenu de la méthode de persistance sortante documentée ici, surveiller les connexions SSH sortantes initiées par des serveurs de niveau infrastructure, et pas seulement l'accès entrant vers eux, fait désormais partie d'une stratégie de détection complète face à cette campagne précise.

Pour les entités essentielles et importantes de l'UE relevant de NIS2 qui exploitaient des instances vCenter accessibles depuis internet ou autrement exposées pendant la fenêtre d'exploitation, cet incident s'inscrit exactement dans les catégories pour lesquelles la directive a été rédigée : une exécution de code à distance non authentifiée sur une infrastructure avec exploitation active confirmée et une réelle possibilité d'atteinte à la confidentialité, à l'intégrité ou à la disponibilité de tout le parc de virtualisation.

À lire ensuite: Une Chaîne de Deux Appels a Livré le Root à 295 Attaquants  |  CVSS 9.6 : faille frappe les load balancers 792 fois