La faille vCenter corrigée le 29 juillet est maintenant exploitée en masse, la France dans le lot

Le 4 août, cet article signalait la publication de VMSA-2026-0006, le correctif d'urgence de Broadcom pour cinq failles VMware vCenter et ESXi, dont deux notées 9,8 sur 10. À l'époque, Broadcom indiquait n'avoir « aucune preuve d'exploitation ». Ce n'est plus le cas.

La société de recherche QUIRSO a publié le 13 août l'analyse d'une campagne d'exploitation active de CVE-2026-59310, l'une des deux failles critiques de ce lot. BleepingComputer, The Hacker News, Zataz et plusieurs autres publications spécialisées ont repris ces travaux le même jour. Les faits, recoupés entre ces sources : 361 adresses IP compromises dans 47 pays, l'exploitation ayant commencé le 3 août, cinq jours seulement après la publication du correctif. L'Allemagne, les États-Unis, la Turquie, l'Iran et la France concentrent la majorité des victimes identifiées, selon SecurityWeek.

Ce que fait la faille

CVE-2026-59310 est une faille de traversée de répertoire dans le serveur syslog de vCenter. Un attaquant ayant simplement un accès réseau à la console — sans compte, sans mot de passe — peut en tirer une exécution de code arbitraire. Selon QUIRSO et BleepingComputer, une fois l'accès obtenu, l'attaquant installe reverse_ssh, un outil de tunnel SSH open source, pour garder un accès distant qui contourne les pare-feux en sortant du réseau plutôt qu'en y entrant. QUIRSO évoque la possibilité d'un acteur étatique derrière la campagne, sans en apporter la preuve à ce stade et sans publier d'indicateurs de compromission détaillés, pour ne pas gêner une coordination en cours avec les autorités.

Broadcom ne propose pas de contournement : la mise à jour est la seule protection.

Qui est concerné

Comme évoqué le 4 août, ESXi reste l'un des systèmes de virtualisation les plus répandus, y compris chez des PME qui font tourner plusieurs machines virtuelles sur un ou deux serveurs physiques. vCenter est la console qui les administre. La nouveauté du 13 août ne change pas le périmètre des entreprises concernées, elle change la nature du risque : on n'est plus dans l'anticipation d'une faille qui pourrait être exploitée, mais dans le constat d'une campagne en cours, avec des victimes déjà comptées en France.

Ce qu'il faut faire aujourd'hui

1. Vérifiez la version de vCenter (vpxd -v sur l'appliance, ou le résumé de l'interface web). Si elle est antérieure aux versions du tableau, la console est exposée depuis le 3 août au moins.
2. Appliquez le correctif sans attendre la prochaine fenêtre de maintenance habituelle. Broadcom ne propose pas d'alternative.
3. Si l'infrastructure est gérée par un prestataire, demandez une confirmation écrite de l'application de VMSA-2026-0006, avec la date exacte.
4. Si le vCenter est resté exposé sur Internet ou accessible largement sur le réseau interne entre le 3 et aujourd'hui sans avoir reçu le correctif, ne présumez pas que la mise à jour suffit à clore le sujet : demandez à votre prestataire de chercher des signes de persistance (tâches planifiées inconnues, connexions SSH sortantes inhabituelles) avant de considérer l'incident clos.
5. En attendant la mise à jour, limitez l'accès réseau à l'interface de gestion de vCenter aux seuls postes d'administration identifiés.

QUIRSO précise avoir mis à disposition une règle YARA générique pour repérer reverse_ssh, mais retient les indicateurs propres à cette campagne le temps de la coordination avec les autorités. Un prestataire de sécurité peut s'appuyer sur cette règle ; une PME sans équipe technique interne doit, à défaut, se fier à la vérification de version et à la mise à jour immédiate.