La faille à 9,8 de VMware : comment 361 serveurs sont tombés en 9 jours après le correctif

Trois failles critiques, un correctif d’urgence

Le 29 juillet 2026, Broadcom a révélé et corrigé trois vulnérabilités critiques affectant des produits de virtualisation VMware essentiels. CVE-2026-59309, un contournement d’authentification dans vCenter, et CVE-2026-59310, une faille de traversée de répertoire permettant l’exécution de code arbitraire, portent toutes deux le score CVSS maximal de sévérité, 9,8. Une troisième faille, CVE-2026-47876, une écriture hors limites dans l’adaptateur réseau virtuel VMXNET3 avec un score CVSS de 9,3, permet à un attaquant disposant de privilèges administratifs locaux à l’intérieur d’une machine virtuelle d’exécuter du code directement sur l’hôte ESXi — un scénario d’évasion de VM qui compromet la promesse fondamentale d’isolation de la virtualisation elle-même.

Les trois vulnérabilités affectent des versions actuelles, activement prises en charge : vCenter 8.0 et Cloud Foundation/vSphere Foundation 9.0.x et 9.1.x pour les deux failles de vCenter, et ESXi 8.0, 9.0.x et 9.1.x pour la faille VMXNET3, selon le compte rendu technique de Rapid7. Des versions corrigées ont été publiées simultanément à la révélation : vCenter 9.1.0.0300, vCenter 9.0.2.0100, vCenter 8.0 U3k ou 8.0 U2f, et les builds ESXi correspondants.

Aucune solution de contournement, donc aucune excuse pour attendre

Le détail qui aurait dû alarmer chaque administrateur VMware le 29 juillet n’est pas le score CVSS en lui-même — les CVE de sévérité critique sont malheureusement routinières — mais l’absence de toute mesure d’atténuation en dehors du correctif. L’avis de Rapid7 énonce clairement qu’« il n’existe aucune solution de contournement pour CVE-2026-59309 ou CVE-2026-59310, faisant des mises à jour fournies par l’éditeur la principale remédiation. » Il n’existait aucune règle de pare-feu, aucun changement de configuration, aucun contrôle compensatoire disponible pour les organisations incapables de corriger immédiatement — seulement la mise à jour elle-même.

Rapid7 a également signalé la raison historique précise pour laquelle vCenter méritait une attention urgente, même avant le début de l’exploitation : le produit était déjà apparu dix fois auparavant sur la liste des vulnérabilités activement exploitées (KEV) de la CISA pour d’autres vulnérabilités — ce qui signifie que les attaquants ont un schéma bien établi consistant à cibler vCenter en priorité dès qu’une nouvelle faille critique devient publique. L’avis de Rapid7 exhortait les clients à « corriger de toute urgence avant que l’exploitation dans la nature ne se produise » — une recommandation qui, avec le recul, a sous-estimé le peu de temps dont disposaient réellement les organisations.

Du correctif à la campagne active en cinq jours

L’écart entre la révélation et l’exploitation a été court. Selon le compte rendu de SecurityWeek, l’exploitation active de CVE-2026-59310 a débuté le 3 août 2026 — seulement cinq jours après la publication du correctif de Broadcom le 29 juillet. À partir de là, le nombre de compromissions a grimpé rapidement : le suivi de BleepingComputer a montré les premiers systèmes compromis se connectant à l’infrastructure des attaquants dès le 3 août, suivis de 151 nouvelles adresses IP victimes observées d’ici le 4 août, 343 adresses IP d’ici le 5 août, et un total de 361 adresses IP dans 47 pays d’ici le 7 août.

L’Allemagne, les États-Unis, la Turquie, l’Iran et la France représentaient plus de la moitié de toutes les victimes identifiées, selon le compte rendu de BleepingComputer. Le groupe de chercheurs en sécurité Quirso, cité par SecurityWeek, a proposé une lecture précise du calendrier : « bien que l’attaquant ait pu avoir une connaissance préalable de la vulnérabilité, la forte corrélation entre la divulgation et l’exploitation suggère que la divulgation a constitué le point de départ initial de la campagne » — en d’autres termes, les notes de correctif et les détails de la CVE eux-mêmes ont probablement servi de feuille de route à l’attaquant.

La charge utile : un shell inversé conçu pour contourner les pare-feux

Une fois à l’intérieur d’un serveur Syslog de vCenter vulnérable, les attaquants ont déployé reverse_ssh, un framework de shell SSH inversé open source, pour établir une persistance. La valeur spécifique de cet outil pour les attaquants tient à son architecture : parce qu’il initie une connexion sortante depuis le serveur compromis vers une infrastructure contrôlée par l’attaquant, plutôt que d’exiger que l’attaquant se connecte de manière entrante, il fonctionne comme un canal de commande et contrôle capable de contourner les règles de pare-feu entrantes standard et d’autres contrôles de sécurité réseau qui supposent que les attaquants doivent entrer, et non que les machines compromises sortiront.

Quirso a publié une règle de détection YARA générique pour les binaires reverse_ssh via son dépôt GitHub public, donnant aux défenseurs un moyen de traquer cette charge utile spécifique même sans savoir si leur propre instance de vCenter avait déjà été compromise. Des chercheurs ont indiqué à SecurityWeek soupçonner l’implication d’une menace persistante avancée (APT) dans cette campagne, mais ont retenu des indicateurs d’attribution spécifiques en attendant une coordination avec les forces de l’ordre — un schéma courant lorsque les enquêteurs estiment qu’une divulgation prématurée pourrait compromettre une enquête active ou alerter l’acteur malveillant.

Ce que cela signifie pour les entreprises exploitant une infrastructure VMware

1. Traitez les avis « sans solution de contournement disponible » comme des urgences automatiques de niveau 1

Lorsqu’un avis d’éditeur indique explicitement qu’aucune atténuation n’existe en dehors du correctif, les délais standard de gestion du changement devraient être outrepassés. Les organisations devraient disposer d’un processus de correctif d’urgence pré-approuvé spécifiquement pour cette catégorie d’avis — pas de solution de contournement, CVSS critique, infrastructure de gestion exposée à internet — capable de s’exécuter dans la fenêtre de cinq jours que cette campagne a démontrée comme réaliste pour l’armement par un attaquant.

2. Vérifiez si votre serveur Syslog de vCenter est exposé à internet

CVE-2026-59310 affecte spécifiquement le composant serveur Syslog de vCenter, et le schéma d’exploitation a ciblé des instances accessibles par le réseau. Les entreprises devraient vérifier que leur infrastructure de gestion vCenter — y compris la fonctionnalité de serveur Syslog — n’est pas exposée à internet public, car l’hypothèse de conception sous-jacente de vCenter est qu’il se trouve sur un réseau de gestion de confiance, et non exposé au public.

3. Déployez la règle YARA reverse_ssh indépendamment de votre statut de correctif

Même les organisations ayant corrigé rapidement devraient exécuter la règle de détection YARA publiée par Quirso sur leur environnement, car la fenêtre d’exploitation de cinq jours signifie que toute instance restée non corrigée entre le 29 juillet et début août aurait pu être compromise avant la remédiation. Corriger ferme la vulnérabilité pour l’avenir ; cela ne supprime pas une charge utile déjà déployée pendant la fenêtre d’exposition.

4. Surveillez les connexions sortantes depuis l’infrastructure de gestion, pas seulement entrantes

La technique d’évasion centrale de l’outil reverse_ssh — les connexions initiées en sortie — met en échec les postures de sécurité construites principalement autour du filtrage entrant. Les équipes de sécurité devraient spécifiquement examiner la surveillance et les alertes de sortie pour vCenter et les autres serveurs de gestion de virtualisation, car ces systèmes n’ont rarement besoin d’initier des connexions SSH sortantes vers des hôtes externes en fonctionnement normal, ce qui fait de telles connexions un signal de détection à haute valeur.

Un schéma que les éditeurs et les défenseurs reconnaissent tous deux

Cet incident correspond à une forme désormais familière dans la sécurité d’entreprise : une faille de sévérité maximale dans un logiciel d’infrastructure largement déployé, aucune solution de contournement, et un calendrier de compromission mesuré en jours à un seul chiffre plutôt qu’en semaines. Ce qui distingue ce cas, c’est la précision des preuves — un écart documenté de cinq jours entre le correctif et la première exploitation, un décompte précis d’adresses IP et de pays suivi jour par jour, et une charge utile nommée et identifiée par empreinte avec une règle de détection publique déjà disponible. Pour les responsables de la sécurité des systèmes d’information gérant une infrastructure de virtualisation, la leçon pratique n’est pas « corrigez VMware » dans l’abstrait, mais un point de référence concret : si un avis vCenter avec CVSS 9,8 et sans solution de contournement peut passer de la divulgation à 361 serveurs compromis en neuf jours, le cycle de correctifs de toute organisation doit être mesuré par rapport à cette horloge, et non par rapport à la commodité interne de la gestion du changement.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution — Rapid7
• Critical VMware vCenter RCE flaw exploited for reverse SSH access — BleepingComputer
• Critical VMware vCenter Vulnerability in Attackers’ Crosshairs — SecurityWeek
• Three Critical VMware Flaws Allow Auth Bypass, Code Execution, and VM Escape — The Hacker News