VMware corrige 3 failles critiques dans vCenter et ESXi — VM escape et RCE sans authentification

Le 29 juillet 2026, Broadcom a dévoilé 5 vulnérabilités dans VMware ESXi, vCenter, Workstation et Fusion. Trois d’entre elles sont critiques, avec des scores CVSS compris entre 9,3 et 9,8. Deux permettent l’exécution de code à distance sur vCenter sans authentification ni interaction utilisateur. La troisième est une VM escape via le pilote VMXNET3 qui permet à un attaquant administrateur local dans une VM de s’échapper vers l’hôte ESXi.

Le message est simple : si votre vCenter est accessible depuis le réseau, il est vulnérable. Si un attaquant compromet votre vCenter, il contrôle vos ESXi. S’il contrôle vos ESXi, il contrôle toutes vos machines virtuelles. La chaîne de compromission est directe et sans friction.

Les 3 failles critiques en détail

CVE-2026-47876 (CVSS 9,3) est une vulnérabilité de type VM escape dans le pilote VMXNET3, le contrôleur réseau paravirtualisé de VMware. Un attaquant disposant de privilèges administrateur local dans une machine virtuelle peut exploiter cette faille pour exécuter du code sur l’hôte ESXi. C’est le scénario redouté par tout administrateur virtualisation : une VM compromise devient le point de départ d’une compromission de l’infrastructure entière. Le vecteur ne nécessite aucune interaction de l’utilisateur de la VM cible, ni aucune configuration réseau particulière au-delà du fonctionnement normal du pilote.

CVE-2026-41703 et CVE-2026-59309 / CVE-2026-59310 sont des vulnérabilités de type remote code execution qui ciblent vCenter Server. L’exploitation est triviale : une requête réseau forgée, sans authentification préalable et sans aucune interaction utilisateur, suffit à exécuter du code arbitraire sur le serveur. Ces trois CVE ciblent des services exposés par défaut sur l’interface de gestion de vCenter. CVE-2026-41703 est le point d’entrée principal ; CVE-2026-59309 et CVE-2026-59310 complètent la chaîne d’exploitation en permettant respectivement l’élévation de privilèges et la persistance sur la machine compromise.

Ces vulnérabilités ont été découvertes par Nguyen Hoang Thach de STARLabs SG dans le cadre du programme Pwn2Own Vancouver 2026 de la Zero Day Initiative (ZDI). Le chercheur a remporté le concours en démontrant une chaîne d’exploitation complète, de la VM invitée jusqu’au contrôle total de l’hyperviseur, validant que ces failles sont non seulement exploitables individuellement mais aussi combinables pour une compromission en profondeur.

vCenter, la clé de voûte qu’on oublie de protéger

vCenter Server est souvent traité comme un outil d’administration interne — une appliance qu’on installe, qu’on expose sur le réseau de gestion et qu’on oublie. C’est une erreur fondamentale. vCenter possède des privilèges administratifs complets sur tous les ESXi qu’il gère. Il détient les identifiants de connexion, les clés de chiffrement des VM, la configuration SSO, les permissions RBAC, les logs d’audit et les politiques de sécurité de l’ensemble du cluster.

Une RCE sans authentification sur vCenter signifie qu’un attaquant peut, en une seule requête réseau :

• Créer un compte administrateur sur l’infrastructure vSphere sans laisser de trace exploitable dans les logs de connexion standards
• Désactiver le chiffrement des machines virtuelles et accéder aux données en clair
• Exfiltrer les snapshots et les sauvegardes vers un serveur externe
• Déployer des VM malveillantes sur l’ensemble des hôtes ESXi du cluster
• Chiffrer les datastores pour une demande de rançon à l’échelle de l’infrastructure
• Désactiver les alertes de monitoring pour masquer l’activité malveillante en cours

Le scénario ransomware est particulièrement réaliste et documenté. Les groupes de ransomware ciblant VMware ESXi ne sont pas nouveaux : LockBit, BlackCat et Akira ont tous développé des variantes spécifiques pour les environnements virtualisés. Une fois vCenter compromis, l’attaquant peut orchestrer le chiffrement de toutes les VM depuis un point central unique, sans avoir à compromettre chaque hôte ESXi individuellement. C’est un multiplicateur de force qui transforme une seule vulnérabilité réseau en un incident de sécurité à l’échelle du datacenter.

Corriger maintenant, ne pas attendre l’exploitation active

Broadcom a publié des correctifs pour l’ensemble des versions affectées de vCenter Server, ESXi, Workstation et Fusion. À la date du 29 juillet 2026, aucune exploitation active n’a été confirmée en conditions réelles. Mais cette situation est évolutive.

Plusieurs signaux justifient une correction immédiate plutôt qu’une attente passive :

• Les détails techniques des CVE sont documentés publiquement par la Zero Day Initiative, avec des descriptions suffisamment précises pour qu’un développeur compétent reconstruise un exploit fonctionnel
• Le chercheur a démontré un exploit complet lors du concours Pwn2Own, validant l’exploitabilité réelle, pas seulement théorique
• La CISA a placé ces vulnérabilités sous surveillance pour une inscription potentielle au catalogue KEV (Known Exploited Vulnerabilities), ce qui déclencherait des obligations de correction pour les agences fédérales américaines et, par effet domino, pour leurs sous-traitants
• CVE-2026-47876 rappelle directement CVE-2025-35079, une VM escape similaire dans VMXNET3 corrigée en juillet 2025, qui avait été exploitée dans les 72 heures suivant la publication des détails techniques

Le précédent de juillet 2025 est éloquent : la VM escape précédente avait été découverte dans des conditions comparables (divulgation coordonnée, PoC public, correctif disponible) et les premières exploitations actives avaient été détectées trois jours plus tard par les honeypots de Shadowserver Foundation. Attendre que les scanners automatisés apparaissent dans vos logs n’est pas une stratégie de défense — c’est une course que vous avez déjà perdue.

Prioriser la surface d’attaque

La correction doit être séquencée par criticité :

1. vCenter Server en premier. Les RCE sans authentification (CVE-2026-41703, CVE-2026-59309, CVE-2026-59310) sont la porte d’entrée la plus directe. Si votre vCenter est accessible depuis un réseau autre que le réseau de gestion dédié, corrigez immédiatement — la compromission est possible en une seule requête HTTP forgée.
2. ESXi en second. La VM escape (CVE-2026-47876) suppose que l’attaquant dispose déjà de privilèges administrateur dans une VM — une barrière plus élevée, mais pas infranchissable dans un environnement multi-tenant ou après une compromission initiale par phishing.
3. Workstation et Fusion en dernier, pour les postes de travail et les environnements de développement.

Le vecteur d’attaque le plus probable pour CVE-2026-47876 est la compromission en deux temps : l’attaquant obtient d’abord un accès administrateur dans une VM (via une application web vulnérable, un RDP exposé ou du phishing), puis utilise la VM escape pour pivoter vers l’hôte ESXi. Dans un datacenter virtualisé, cette VM peut être hébergée sur le même cluster que vos serveurs de production, et l’isolation entre VM n’offre aucune protection contre une VM escape.

Un pattern VMware qui se répète

Cette série de correctifs s’inscrit dans un schéma préoccupant. En janvier 2025, Broadcom avait corrigé une zero-day activement exploitée dans ESXi — un ensemble de trois CVE (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226) permettant à un attaquant disposant de privilèges admin VM de s’échapper vers l’hôte. En juillet 2025, CVE-2025-35079 reproduisait le même scénario via VMXNET3, avec un score CVSS de 9,3. En juillet 2026, CVE-2026-47876 récidive sur le même composant, avec le même score.

Le pilote VMXNET3 est un point de jonction critique entre la VM et l’hyperviseur. Il gère les files de paquets réseau partagées entre l’invité et l’hôte, avec des structures de données en mémoire qui traversent la frontière de virtualisation. Chaque bug de validation d’entrée dans ce pilote a le potentiel de devenir une VM escape, et trois occurrences en dix-huit mois sur le même composant suggèrent que la surface d’attaque de VMXNET3 n’est pas maîtrisée et mérite un audit de sécurité approfondi.

Pour les RSSI, ce pattern justifie une posture plus agressive que le simple patching réactif :

• Isoler vCenter sur un réseau de gestion physiquement séparé ou au minimum un VLAN dédié avec bastion d’accès et authentification multi-facteurs
• Restreindre les snapshots VM aux comptes de backup uniquement et surveiller les créations de snapshots hors plage de sauvegarde planifiée
• Surveiller les logs vCenter pour les créations de comptes anormales, les élévations de privilèges, les changements de rôle et les désactivations d’alertes
• Segmenter les VM par niveau de sensibilité sur des clusters ESXi distincts pour limiter le rayon d’impact d’une VM escape
• Désactiver VMXNET3 sur les VM qui n’ont pas besoin de performances réseau paravirtualisées et peuvent fonctionner avec le pilote E1000E standard

Verdict

Appliquez les correctifs dans les 48 heures sur vCenter, la fenêtre est trop courte pour un cycle de change management classique. Si votre vCenter est exposé sur un réseau non dédié, la correction est une urgence absolue : les RCE sans authentification ne nécessitent qu’une seule requête pour compromettre l’infrastructure, et les détails techniques sont publics.

Si la correction immédiate est impossible pour des raisons opérationnelles, appliquez ces mesures de contournement sans délai : restreignez l’accès réseau à vCenter via un pare-feu ou un VPN avec authentification forte, désactivez les comptes de service inutilisés, et activez la journalisation complète des appels API vCenter pour détecter une activité anormale. Ces mesures ne remplacent pas le correctif — elles réduisent la surface d’attaque en attendant son application.

La question n’est pas de savoir si des exploits publics vont apparaître. La question est de savoir si vous aurez déjà corrigé quand ils apparaîtront.

Références

• VMware Security Advisory VMSA-2026-0015, Broadcom, 29 juillet 2026.
• Pwn2Own Vancouver 2026 — VMware Exploit Chain, Trend Micro Zero Day Initiative, 29 juillet 2026.
• CISA Known Exploited Vulnerabilities Catalog, Cybersecurity and Infrastructure Security Agency.
• VMware ESXi zero-day exploited by ransomware groups, BleepingComputer, janvier 2025.
• VMware corrige une faille VM escape dans VMXNET3 (CVE-2025-35079), IT-Connect, juillet 2025.
• Shadowserver Foundation — Internet Storm Center, Shadowserver Foundation.