Broadcom a déployé de nouvelles mises à jour de sécurité pour VMware vCenter, ESX/ESXi, Workstation et Fusion. L’alerte est particulièrement forte : l’éditeur indique que trois failles critiques VMware peuvent, selon les cas, contourner l’authentification, exécuter du code arbitraire ou provoquer une évasion de machine virtuelle vers l’hôte.
Dans ce contexte, l’objectif est clair : identifier vos versions, appliquer les correctifs dès que possible et limiter l’impact opérationnel pendant les redémarrages et migrations nécessaires. Voici l’essentiel, avec les points d’attention les plus importants.
Pourquoi ces failles critiques VMware exigent une action rapide
Broadcom traite ces corrections comme des mesures d’urgence. L’éditeur prévient que les organisations utilisant des versions antérieures à celles listées comme corrigées doivent considérer qu’elles sont vulnérables, et agir sans attendre.
Les raisons sont à la fois techniques et pratiques. D’un côté, deux vulnérabilités touchent vCenter et permettent des attaques à distance sans authentification. De l’autre, une faille liée à l’adaptateur réseau VMXNET3 peut mener à une exécution de code sur l’hôte ESX/ESXi, avec des conséquences typiques d’une évasion VM.
Les trois failles critiques VMware : ce qu’elles permettent
1) Contournement d’authentification dans VMware Directory Service (CVE-2026-59309)
La première vulnérabilité critique porte le code CVE-2026-59309. Elle concerne le service Directory de VMware et autorise un contournement d’authentification.
Selon Broadcom, un attaquant non authentifié disposant d’un accès réseau à vCenter peut exploiter la faille pour bypass l’authentification et obtenir un accès non autorisé au système.
2) Traversée de répertoires dans le serveur Syslog de vCenter (CVE-2026-59310)
La deuxième faille critique, CVE-2026-59310, vise le serveur Syslog de vCenter. Broadcom décrit une vulnérabilité de directory traversal qui peut conduire à l’exécution de code arbitraire.
Comme pour la précédente, l’attaque est réalisable par un adversaire non authentifié disposant d’un accès réseau. L’impact est donc potentiellement immédiat si l’exposition réseau de vCenter est existante.
3) Évasion de machine virtuelle via VMXNET3 (CVE-2026-47876)
Enfin, CVE-2026-47876 concerne un write out-of-bounds dans l’adaptateur réseau virtuel VMXNET3. Broadcom indique que l’attaquant doit avoir des privilèges administratifs locaux à l’intérieur de la machine virtuelle.
Une fois la faille exploitée, elle peut permettre l’exécution de code sur l’hôte ESX/ESXi, entraînant une évasion de machine virtuelle. Important : Broadcom précise que les VM utilisant d’autres adaptateurs réseau virtuels ne sont pas concernées par cette vulnérabilité.
Les autres vulnérabilités corrigées (de gravité inférieure)
Au-delà des trois failles critiques, Broadcom corrige aussi deux autres problèmes importants et une faiblesse liée à la journalisation.
- CVE-2026-41703 : out-of-bounds read sur ESX, Workstation et Fusion. L’exploitation dépend de privilèges liés au déploiement de VM. Sur ESX, l’impact peut aller de la divulgation d’informations à un déni de service ; sur Workstation et Fusion, Broadcom limite l’impact à une divulgation d’informations.
- CVE-2026-41709 : vulnérabilité d’insuffisance de logging. Elle pourrait permettre à un administrateur ESX malveillant d’effectuer certaines opérations sans que celles-ci soient correctement consignées.
Broadcom attribue des scores différents aux vulnérabilités : les deux problèmes vCenter ont un niveau très élevé (CVSS 9.8), tandis que la faille d’évasion liée à VMXNET3 est également notée comme extrêmement sévère (CVSS 9.3). Les autres issues sont présentées comme moins critiques selon les évaluations fournies par l’éditeur.
Versions concernées et correctifs : où commencer
La mise à jour dépend de votre produit et de votre version. Broadcom liste les changements par composant.
vCenter
Les correctifs vCenter sont annoncés pour :
- 9.1.0.0300
- 9.0.2.0100
- 8.0 Update 3k
ESX/ESXi
Pour ESXi, les mises à jour s’appliquent aux versions :
- 9.1.0.0200
- 9.0.2.0100
- 8.0 Update 3k
Workstation et Fusion
Pour Workstation et Fusion, Broadcom indique que les utilisateurs en 25H2 doivent passer à 26H1 afin de corriger CVE-2026-41703.
Pour VMware Cloud Foundation 5.x et les produits “telco” concernés, l’éditeur précise que les procédures de patching sont distinctes et renvoyées à des instructions spécifiques dans l’avis de sécurité.
Pas de contournement : pourquoi éviter les demi-mesures
Broadcom signale qu’il n’existe pas de solution de contournement (“workaround”) pour ces vulnérabilités. De plus, l’éditeur déconseille de compter uniquement sur une action “simple” comme le déplacement des machines virtuelles hors de l’adaptateur VMXNET3.
En effet, Broadcom indique que d’autres adaptateurs réseau virtuels ont eux aussi pu contenir des failles, ce qui pourrait réduire la performance ou créer une fausse impression de sécurité. Autrement dit : la mise à jour reste l’approche la plus fiable.
Planifier la mise à jour sans casser l’exploitation
Au moment d’appliquer les correctifs, attendez-vous à des impacts opérationnels. Broadcom prévient que le patching de vCenter peut interrompre temporairement l’accès au vSphere Client et à d’autres interfaces de gestion.
En revanche, les machines virtuelles et les conteneurs continuent de fonctionner pendant cette phase. Le point clé devient donc la coordination avec l’équipe IT pour réduire le temps d’indisponibilité des interfaces.
ESX/ESXi : redémarrage et migration conseillées
Pour ESX/ESXi, Broadcom recommande l’utilisation de vMotion afin de déplacer les machines virtuelles vers d’autres hôtes pendant la mise à jour, notamment dans un contexte de rolling reboot (redémarrages successifs hôte par hôte).
Si une VM ne peut pas être migrée, Broadcom conseille de la mettre hors tension pendant le redémarrage nécessaire.
Dans des environnements compatibles, l’éditeur mentionne aussi ESX Live Patch pour limiter la disruption. Attention : les mises à jour liées à vCenter ne sont pas éligibles à la fonctionnalité Quick Patch selon Broadcom.
Compatibilité à surveiller avec VMware Cloud Foundation
Un autre point important concerne la compatibilité lors de la mise à niveau de VMware Cloud Foundation. Broadcom évoque un comportement de type “back in time” (retour en arrière) lors de certains scénarios d’upgrade.
Le principe est le suivant : une branche de produit mise à jour peut porter un numéro de build plus récent que la cible de la mise à niveau planifiée. Dans ce cas, l’upgrade peut être bloqué avec un message d’erreur “back in time”.
Broadcom indique que la compatibilité sera rétablie dans des versions ultérieures.
Exposition réelle : pourquoi les admins ne doivent pas attendre
Broadcom affirme ne pas avoir de preuve d’exploitation active de ces vulnérabilités dans la nature. Pourtant, l’éditeur rappelle un constat général : les serveurs VMware sont souvent ciblés, car compromettre un vCenter ou ESXi peut offrir un accès à une large portion de l’infrastructure et aux données hébergées.
Les attaques orientées “ransomware” et la compromission de machines virtuelles sont devenues un modèle fréquent. Dans ce cadre, les organisations doivent traiter les mises à jour comme une priorité, même en l’absence d’exploitation observée pour ces CVE précis.
Checklist d’action en urgence
Pour passer du constat à l’exécution, voici une approche simple inspirée par les recommandations de Broadcom :
- Inventorier vos versions de vCenter, ESXi/ESX, Workstation et Fusion.
- Comparer chaque version aux numéros annoncés comme corrigés par l’avis.
- Planifier l’impact : interruption d’accès au client pour vCenter, redémarrages pour ESXi, migrations via vMotion quand possible.
- Éviter de “contourner” via des changements d’adaptateur réseau à la place du correctif.
- Valider la compatibilité si vous utilisez VMware Cloud Foundation 5.x, telco ou Telco Cloud Infrastructure.
Enfin, gardez à l’esprit que ces correctifs relèvent d’un changement d’urgence : le but est de réduire le délai d’exposition, sans attendre une prochaine fenêtre de maintenance trop lointaine.
Conclusion
Les failles critiques VMware publiées par Broadcom concernent directement vCenter et l’hôte via une faille liée à VMXNET3. Même si aucune exploitation réelle n’est signalée à ce stade, la sévérité des impacts et la nature des vecteurs d’attaque rendent la mise à jour prioritaire.
En appliquant les versions corrigées et en planifiant soigneusement les interruptions, vous réduisez fortement le risque qu’un attaquant transforme vos environnements virtuels en point d’entrée.
