CVE-2026-59310 : ce que révèle la campagne visant VMware vCenter

CVE-2026-59310 n’est plus seulement une vulnérabilité à corriger en urgence. Cette faille critique du serveur Syslog de VMware vCenter a été divulguée et corrigée par Broadcom le 29 juillet 2026, mais des chercheurs ont observé les premiers signes d’exploitation dès le 3 août, soit cinq jours plus tard. La campagne a concerné 361 adresses IP observées dans 47 pays et s’est appuyée sur le reverse SSH pour conserver un accès aux systèmes. Pour Shadowserver, les environnements où ce mécanisme a été déployé doivent être considérés comme entièrement compromis.

Ce que permet CVE-2026-59310

Broadcom et la National Vulnerability Database (NVD), la base américaine de référence sur les vulnérabilités, décrivent CVE-2026-59310 comme une faille de traversée de répertoires dans le serveur Syslog de vCenter. Un attaquant disposant d’un accès réseau à vCenter peut l’exploiter sans authentification afin d’exécuter du code arbitraire sur le système vulnérable. La faille affiche un score CVSS de 9,8, correspondant au niveau de gravité critique.

Concrètement, une appliance vCenter exposée peut devenir un point d’entrée vers l’infrastructure virtuelle de l’organisation. Les informations publiées sur la campagne évoquent une exécution dans le contexte root de l’appliance, mais les descriptions les plus autorisées de Broadcom et de la NVD établissent surtout le risque général d’exécution de code arbitraire, sans détailler les privilèges obtenus dans chaque intrusion.

Broadcom a publié des versions corrigées, mais aucun contournement temporaire. L’application des mises à jour indiquées par l’éditeur constitue donc la mesure officielle de remédiation pour les systèmes vulnérables.

Une exploitation cinq jours après la publication du correctif

Broadcom a divulgué CVE-2026-59310 et publié les correctifs le 29 juillet. QUIRSO a signalé des indices d’exploitation active à partir du 3 août, avant une expansion rapide de la campagne.

Cette chronologie est particulièrement importante pour la réponse à incident. Un système mis à jour après le 3 août ne doit pas être considéré comme sain uniquement parce que l’installation du correctif s’est déroulée correctement. Il faut distinguer deux actions : corriger la vulnérabilité, puis vérifier si un attaquant avait déjà obtenu un accès et installé une persistance.

361 adresses IP dans 47 pays

Les chercheurs ont associé l’activité à 361 adresses IP victimes observées dans 47 pays. L’Allemagne, les États-Unis, la Turquie, l’Iran et la France représenteraient à eux seuls plus de la moitié de l’ensemble observé.

Ce chiffre doit toutefois être interprété avec prudence. Une adresse IP ne correspond pas nécessairement à une organisation unique : « 361 victimes » ne signifie donc pas forcément 361 entreprises ou institutions distinctes. Les données disponibles décrivent néanmoins une campagne de grande ampleur visant des systèmes vCenter accessibles depuis Internet ou exposés sur le réseau.

Pourquoi un lien avec la Chine est évoqué

QUIRSO évalue avec une confiance modérée l’hypothèse d’un lien chinois. Les éléments cités comprennent des artefacts en langue chinoise, des outils et des travaux de recherche réutilisés publiquement, une activité compatible avec des horaires de travail en UTC+08:00, ainsi qu’un ciblage qui aurait épargné la Chine continentale.

Ces indices peuvent étayer une évaluation régionale ou linguistique, mais ils ne permettent pas d’identifier un groupe étatique chinois précis ni de démontrer une implication gouvernementale. L’attribution fondée sur des artefacts, des horaires et le profil des victimes peut évoluer avec l’arrivée de nouvelles preuves. La formulation la plus rigoureuse reste donc celle d’un « acteur présumé lié à la Chine », et non celle d’une opération étatique confirmée.

La chaîne d’intrusion rapportée

La campagne semble avoir utilisé CVE-2026-59310 pour obtenir l’exécution initiale, avant de déployer plusieurs niveaux de persistance et d’accès :

1. Traversée de répertoires : des requêtes spécialement conçues pour le service Syslog auraient permis de sortir du chemin prévu et d’y écrire du contenu contrôlé par l’attaquant.
2. Persistance par cron : les attaquants auraient créé des entrées cron malformées afin de lancer des commandes ultérieures.
3. Livraison d’une porte dérobée : selon les informations publiées sur les intrusions observées, curl ou wget récupérait une porte dérobée nommée linuxFile, obfusquée par WebSocket et XOR.
4. Reverse SSH : des outils de reverse SSH étaient installés pour établir une connexion sortante vers une infrastructure contrôlée par les attaquants. Shadowserver indique que ce mécanisme de persistance a été retrouvé chez toutes les victimes de son rapport spécial.
5. Abus de comptes et d’identifiants : les enquêteurs ont signalé des comptes administrateurs vCenter et ESXi créés ou utilisés sans autorisation, ainsi qu’un abus d’identifiants du VMware Directory Service.
6. Déploiement d’un rançongiciel : certaines sources relient l’activité à une variante de rançongiciel dérivée de Babuk, qui ajoute l’extension .babyk.

La présence du reverse SSH est le point le plus préoccupant. Pour Shadowserver, les systèmes concernés doivent être traités comme entièrement compromis. Supprimer un binaire ou une tâche cron sans reconstruire la confiance dans l’appliance et renouveler les identifiants privilégiés ne constitue pas une stratégie de rétablissement suffisante.

Le rançongiciel a peut-être servi à effacer les traces

L’activité associée à l’extension .babyk ne correspond pas nécessairement à une campagne classique de rançongiciel visant avant tout le chiffrement massif et l’extorsion. Des analystes ont suggéré que le chiffrement sélectif de journaux ESXi pouvait avoir pour objectif de perturber l’enquête et de masquer des preuves.

Cette interprétation reste une hypothèse des analystes, et non une intention confirmée par les attaquants. Les équipes de défense doivent néanmoins examiner les deux scénarios : un impact du rançongiciel sur les machines virtuelles et une altération délibérée des journaux destinée à dissimuler l’intrusion.

Des outils dissimulés sur GitHub

Des informations publiées sur l’opération font également le lien avec un dépôt GitHub qui présentait des binaires de reverse SSH comme un utilitaire Linux de nettoyage des fichiers temporaires. Dissimuler un outil de persistance derrière un programme d’administration ou de nettoyage peut faciliter sa distribution et le rendre moins visible lors d’un contrôle courant. Les éléments disponibles ne permettent toutefois pas d’établir indépendamment l’identité de l’opérateur du dépôt : son existence ne constitue donc pas une preuve d’attribution.

Quel impact pour Broadcom ?

L’action Broadcom a reculé d’environ 5 à 6 % le 14 août, alors que les informations sur l’exploitation active de VMware vCenter atteignaient les investisseurs. Une source décrit un passage de 417,82 à 392,99 dollars au cours de la séance.

Les alertes de cybersécurité ont contribué à la pression sur le titre, mais elles n’en expliquent pas nécessairement tout le recul. La couverture financière de la même période mentionnait aussi d’autres préoccupations, notamment l’exposition à la dette liée à l’intelligence artificielle. Il serait donc imprudent d’attribuer à CVE-2026-59310 l’intégralité de la baisse ou un montant précis de capitalisation boursière effacé.

Les informations disponibles ne suffisent pas non plus à conclure que la campagne a déjà entraîné une baisse mesurable du chiffre d’affaires de VMware. Les effets commerciaux à court terme les mieux étayés sont plutôt les coûts de remédiation pour les clients, le risque de perturbations opérationnelles et la pression sur la réputation. Une éventuelle incidence durable sur les revenus nécessiterait des communications de l’entreprise ou de nouvelles données financières.

Que doivent faire les administrateurs vCenter ?

Le correctif est indispensable, mais il ne constitue pas la fin de l’intervention. Les organisations devraient :

1. Installer immédiatement les versions corrigées de Broadcom sur chaque instance vCenter concernée, en donnant la priorité aux systèmes exposés à Internet ou accessibles depuis de larges segments internes. Broadcom ne fournit aucun contournement.
2. Présumer une compromission lorsque des indicateurs sont présents, notamment des modifications inattendues de cron, des artefacts de reverse SSH, linuxFile, des téléchargements inexpliqués via curl ou wget, des comptes administrateurs vCenter ou ESXi inconnus et une activité anormale du VMware Directory Service.
3. Isoler les appliances suspectes et conserver, lorsque les conditions opérationnelles le permettent, les images disque, les journaux et les éléments volatils avant toute reconstruction.
4. Renouveler les identifiants privilégiés, notamment ceux du SSO vCenter, du VMware Directory Service, d’ESXi ou de root, des API, des comptes de service et des comptes administratifs liés. Les sessions actives doivent être invalidées et les chemins de fédération vérifiés.
5. Reconstruire plutôt que simplement nettoyer les systèmes où une persistance a été confirmée. La suppression des comptes non autorisés, tâches cron, binaires, clés SSH et tunnels doit s’inscrire dans un processus documenté de réponse à incident.
6. Rechercher les signes d’activité dans toute l’infrastructure virtuelle, notamment l’extension .babyk, des connexions SSH ou WebSocket sortantes inattendues, des comptes clandestins et des traces d’altération des journaux ESXi.
7. Restaurer des données et une télémétrie fiables à partir de sauvegardes connues comme saines et immuables lorsque les journaux ou les configurations ont été modifiés.

La conclusion opérationnelle est simple : il faut mettre à jour chaque système vCenter vulnérable, mais une mise à jour réussie ne garantit pas un environnement propre. L’exploitation rapide, la persistance par reverse SSH et les abus d’identifiants rapportés imposent d’examiner les appliances exposées comme des systèmes potentiellement entièrement compromis.