VMware vCenter CVE-2026-59310 CVSS 9.8 : exploitation mondiale active

Les faits

Le 29 juillet 2026, Broadcom publiait un avis de sécurité critique concernant CVE-2026-59310, une vulnérabilité de traversée de répertoire (directory traversal) affectant le composant Syslog Server intégré à VMware vCenter. La faille obtient un score CVSS 3.1 de 9.8 — la notation la plus sévère atteignable en pratique — car elle est exploitable sans aucune authentification préalable par tout attaquant disposant d'un simple accès réseau au port de gestion de l'appliance vCenter.

Le mécanisme d'exploitation est redoutablement simple. Le composant Syslog de vCenter ne valide pas correctement les chemins de fichiers transmis dans certaines requêtes réseau entrantes. Un attaquant peut injecter des séquences de traversée de répertoire pour écrire des fichiers arbitraires en dehors du répertoire racine prévu. Cette capacité d'écriture arbitraire suffit à déclencher une exécution de code distant (RCE) non authentifiée sur l'appliance vCenter, ouvrant un accès administratif complet à l'ensemble de l'infrastructure virtualisée gérée.

Cinq jours seulement après la divulgation publique, le 3 août 2026, la société allemande de réponse sur incident QUIRSO détectait une campagne d'exploitation active à grande échelle. Leurs analyses révèlent qu'un acteur de menace unique cible de manière systématique les serveurs vCenter exposés sur Internet. Au 7 août 2026, QUIRSO avait identifié 361 adresses IP victimes réparties dans 47 pays. Les pays les plus représentés parmi les victimes sont l'Allemagne, les États-Unis, la Turquie, l'Iran et la France. Ce délai de cinq jours entre divulgation et exploitation opérationnelle à grande échelle illustre la capacité croissante des acteurs de menace à industrialiser rapidement l'exploitation de nouvelles CVE critiques.

La chaîne d'attaque documentée par QUIRSO et relayée par BleepingComputer le 12 août 2026 suit un schéma reproductible en trois étapes. Première étape : l'attaquant exploite CVE-2026-59310 pour écrire un fichier malveillant sur l'appliance via la traversée de répertoire. Deuxième étape : il déploie reverse_ssh, un outil open source de reverse shell SSH écrit en Go, qui initie une connexion sortante persistante vers l'infrastructure de commande et contrôle de l'attaquant — contournant ainsi les pare-feux configurés pour bloquer uniquement les connexions entrantes. Troisième étape : un cron job malveillant est créé dans /etc/cron.d/ pour relancer automatiquement reverse_ssh au redémarrage, garantissant une persistance durable même après un reboot de l'appliance.

VMware vCenter est un composant fondamental dans les architectures virtualisées d'entreprise et de datacenter : il assure la gestion centralisée de l'ensemble des hyperviseurs ESXi et des machines virtuelles. Une compromission de vCenter équivaut en pratique à la compromission totale de toute l'infrastructure virtuelle — toutes les VM, tous les datastores, toutes les configurations réseau et de stockage. L'attaquant dispose d'un point de contrôle idéal pour se déplacer latéralement sans restriction, exfiltrer des données, déployer un ransomware sur l'ensemble des VM simultanément, ou sabotager des systèmes ciblés.

Broadcom a confirmé dans la FAQ accompagnant son avis de sécurité qu'aucun contournement ou mesure d'atténuation temporaire n'existe pour CVE-2026-59310. La seule protection valide est l'application du patch. Les versions corrigées sont vCenter Server 7.0 U3u et 8.0 U3j, disponibles depuis le 29 juillet 2026. La société avait initialement déclaré n'avoir observé aucune exploitation active — cette situation a changé dans les 120 heures suivantes.

SecurityWeek et The Hacker News ont tous deux couvert l'explosion de l'exploitation active, soulignant que les 361 adresses IP identifiées par QUIRSO ne représentent probablement qu'une fraction des systèmes réellement compromis. La télémétrie passive a des limites structurelles : elle ne capture que les victimes dont le trafic réseau est visible depuis les points d'observation disponibles. Le nombre réel de vCenter compromis est vraisemblablement supérieur d'un facteur significatif.

Dark Reading, dans son analyse du 13 août 2026, souligne qu'une campagne d'exploitation d'une telle ampleur — 361 victimes dans 47 pays en quatre jours — suggère soit un acteur disposant de ressources importantes, soit un groupe criminel ayant automatisé l'exploitation via des outils de scan massif couplés à un exploit fiable. L'utilisation de reverse_ssh, outil open source publiquement disponible, ne permet pas d'établir une attribution certaine de l'attaquant.

Infosecurity Magazine précise que le délai de cinq jours entre divulgation et exploitation confirme une tendance documentée depuis 2024 : les acteurs de menace disposent désormais de capacités d'ingénierie inverse suffisamment matures pour passer d'un bulletin de sécurité à une exploitation opérationnelle en quelques jours pour les vulnérabilités les plus accessibles à exploiter.

Impact et exposition

Toute organisation disposant d'une instance VMware vCenter Server exposée directement sur Internet ou accessible depuis un réseau insuffisamment cloisonné est à risque. Les environnements les plus exposés sont les datacenters d'hébergeurs, les ESN et MSP gérant des infrastructures mutualisées, ainsi que les grandes entreprises dont vCenter est accessible depuis des VLAN non segmentés. Si votre vCenter était exposé avant le 29 juillet 2026 sans le patch, il convient de considérer une compromission potentielle et de procéder à un audit forensic complet. La faille ne nécessitant aucune authentification, une exposition même brève peut suffire à déclencher une compromission complète.

Recommandations

• Appliquer immédiatement les patches vCenter Server 7.0 U3u ou 8.0 U3j selon votre version — sans délai
• Vérifier les cron jobs sur l'appliance (/etc/cron.d/, /var/spool/cron/) et auditer les processus réseau sortants suspects vers des IP inconnues
• Restreindre l'accès au port de gestion vCenter (443/TCP) aux seules adresses IP administratives via ACL ou règles de pare-feu strictes
• Effectuer un audit de compromission (forensic) si vCenter était exposé entre le 29 juillet et la date d'application du patch
• Surveiller les connexions SSH sortantes initiées depuis l'appliance vCenter vers des adresses IP externes non répertoriées