En bref

  • CVE-2026-59310 (CVSS 9.8) : traversée de répertoire dans vCenter Syslog permettant une RCE root sans authentification ni interaction utilisateur
  • 361 victimes confirmées dans 47 pays début septembre 2026 — délai d'exploitation mesurable en jours après la divulgation du 29 juillet
  • Patcher immédiatement vers vCenter Server 8.0 U3k, VMware Cloud Foundation 9.1.0.0300 ou 9.0.2.0100

Les faits

Broadcom a divulgué le 29 juillet 2026 CVE-2026-59310, une vulnérabilité critique de traversée de répertoire (path traversal) dans le service Syslog de VMware vCenter Server. Avec un score CVSS de 9.8, la faille permet à un attaquant non authentifié disposant d'un accès réseau à vCenter d'exécuter du code arbitraire avec des privilèges root. L'exploitation ne requiert ni credentials, ni accès préalable, ni interaction utilisateur — le vecteur réseau critique le plus redouté.

Techniquement, la vulnérabilité exploite une insuffisance de validation des entrées dans le service Syslog de vCenter. Un attaquant envoie une requête HTTP vers l'endpoint Syslog avec un composant de chemin malveillant contenant des séquences de traversée (../../ ou leurs équivalents URL-encodés %2e%2e%2f), lui permettant d'écrire des fichiers arbitraires en dehors du répertoire Syslog légitime — partout où le compte de service vCenter possède des droits d'écriture. En pratique : écriture d'un webshell ou d'un binaire dans un chemin exécutable, aboutissant à une RCE root complète.

La vitesse de passage de la divulgation à l'exploitation généralisée a été particulièrement courte. Les chercheurs du Cloud Security Alliance (CSA) ont confirmé début septembre 2026 que 361 adresses IP victimes uniques avaient été identifiées dans 47 pays, dont des entreprises françaises. Ce chiffre représente uniquement les cas documentés — les chercheurs estiment que l'exploitation réelle est sensiblement supérieure.

Le mode opératoire est structuré en deux phases documentées par BleepingComputer et CyberSecurityNews. Dans un premier temps, les attaquants exploitent CVE-2026-59310 pour déposer un binaire SSH inverse sur le vCenter compromis, établissant un tunnel persistant vers leur infrastructure C2. Cette persistance SSH est discrète : elle ne génère pas les alertes VMware classiques liées aux connexions vSphere ou modifications d'infrastructure.

Dans un second temps, après reconnaissance du réseau virtualisé — inventaire des datastores, snapshots, sauvegardes accessibles — les attaquants pivotent vers les hôtes ESXi pour déployer une variante du ransomware Babuk. Babuk, dont le code source a été leaké en 2021, reste la base de nombreuses souches ransomware ciblant spécifiquement VMware ESXi. Son déploiement chiffre les fichiers VMDK des datastores, rendant toutes les machines virtuelles inaccessibles. Les sauvegardes co-localisées dans le même réseau de stockage sont systématiquement ciblées et chiffrées en priorité.

Les versions concernées incluent vCenter Server 8.0 (toutes versions antérieures à 8.0 U3k), VMware Cloud Foundation / vSphere Foundation (antérieures à 9.1.0.0300 ou 9.0.2.0100), et vCenter Server 7.0. La CISA a ajouté CVE-2026-59310 au catalogue KEV. Le BSI allemand et plusieurs CERT européens ont émis des alertes dans la première semaine de septembre 2026 à destination des opérateurs d'infrastructure critique.

Le contexte aggravant est la surexposition historique de vCenter. Des scans Shodan réalisés fin juillet montraient plus de 12 000 instances vCenter exposant le port 443 directement sur Internet sans authentification préalable (VPN, bastion, restriction IP). Ce chiffre a baissé depuis la divulgation, mais les chercheurs du CSA estiment que plusieurs milliers d'instances non patchées restent directement accessibles début septembre 2026.

La compromission de vCenter est fonctionnellement équivalente à une compromission totale de l'infrastructure : accès aux consoles de toutes les VM, aux datastores, aux snapshots, aux credentials dans les profils de connexion vSphere, et capacité à déployer des VM malveillantes. Dans les environnements sans backup off-site immutable, une attaque Babuk via CVE-2026-59310 peut être irréversible sans payer la rançon.

Impact et exposition

Tout vCenter Server 8.0 antérieur à U3k et tout VMware Cloud Foundation antérieur à 9.1.0.0300 exposant le port 443/TCP à un réseau non de confiance est directement exploitable sans interaction. L'impact d'une compromission vCenter est maximal : l'ensemble de l'infrastructure virtualisée devient accessible. Les sauvegardes stockées dans le même réseau de stockage sont également à risque. Les environnements sans backup off-site ou immutable sont dans la situation la plus critique.

Recommandations

  • Patcher immédiatement vers vCenter Server 8.0 U3k ou VMware Cloud Foundation 9.1.0.0300 (référencer le VMSA-2026-0019 de Broadcom)
  • Restreindre l'accès réseau au port 443 de vCenter au strict nécessaire — accessible uniquement depuis le réseau de management IT via VPN ou segment dédié
  • Rechercher des IoC : binaires SSH inconnus sur l'hôte vCenter, connexions sortantes persistantes, fichiers récents dans /tmp et répertoires webroot
  • Vérifier l'intégrité et l'accessibilité des sauvegardes ESXi sur supports off-site ou immutables (stockage immutable S3, bandes hors ligne)
  • Activer le logging détaillé et forwarder vers SIEM pour détecter des séquences de traversée de chemin dans les logs d'accès vCenter

Alerte critique

Si votre vCenter a été accessible depuis un réseau non contrôlé depuis le 29 juillet 2026 sans être patché, considérez un incident possible. Avec 361 victimes documentées dans 47 pays et un délai d'exploitation de quelques jours, le risque est élevé. Avant d'appliquer le patch, vérifiez les indicateurs de compromission — patcher peut effacer des traces forensiques critiques.

Comment détecter une exploitation avant d'appliquer le patch, sans détruire les preuves forensiques ?

Dans l'ordre : (1) Exportez d'abord les logs d'accès depuis /var/log/vmware/vpxd/ et recherchez des requêtes HTTP contenant ../../ ou %2e%2e vers l'endpoint Syslog entre le 29 juillet et aujourd'hui. (2) Listez les connexions réseau actives avec netstat -antp et cherchez des connexions SSH sortantes vers des IP inconnues. (3) Inventoriez les fichiers créés ou modifiés après le 29 juillet dans /tmp, /var/tmp et les répertoires webroot. (4) Vérifiez /root/.ssh/authorized_keys pour des clés non autorisées. Si des anomalies sont détectées, préservez une image disque avant de patcher et contactez un prestataire de réponse à incident.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit