VMware Workstation et Fusion : deux failles permettent de s’échapper de la machine virtuelle

Broadcom a récemment corrigé deux vulnérabilités critiques dans VMware Workstation et VMware Fusion. Toutes deux peuvent permettre à un attaquant disposant de privilèges administrateur dans la machine virtuelle d’exécuter du code sur le système hôte.

La plus critique, CVE-2026-59346, affiche un score CVSS de 9.3 et est due à un dépassement d’entier (integer overflow). La seconde, CVE-2026-59347, est un dépassement de tampon basé sur la pile (stack-based buffer overflow) évalué à CVSS 8.1.

Les versions 25H2 et 26H1 des deux produits sont concernées. Le correctif est inclus dans la version 26H1u1 et aucun contournement alternatif à la mise à jour n’a été communiqué.

Deux chemins différents de la machine virtuelle vers l’hôte

Le point commun de ces vulnérabilités est le franchissement de la frontière de sécurité entre le guest et l’hôte. La virtualisation doit isoler les logiciels exécutés dans la machine virtuelle du système qui l’héberge ; ces failles permettent toutefois de contourner cette séparation dans certaines conditions.

Pour exploiter CVE-2026-59346, l’attaquant doit déjà disposer de privilèges administrateur locaux au sein du guest. La machine virtuelle doit également utiliser un adaptateur réseau virtuel VMXNET3.

La faille est classée comme un dépassement d’entier. De manière générale, cette catégorie de vulnérabilité survient lorsqu’une opération arithmétique produit une valeur qui ne peut pas être représentée dans l’espace prévu. Le résultat peut fausser des calculs liés aux tailles, aux offsets ou aux allocations mémoire, créant ainsi des conditions exploitables.

Le parcours de traitement précis dans VMXNET3 contenant l’erreur n’a pas été divulgué, pas plus que la séquence technique nécessaire pour la déclencher. L’impact indiqué est toutefois clair : une attaque réussie peut conduire à l’exécution arbitraire de code sur l’hôte.

CVE-2026-59347 nécessite elle aussi des privilèges administrateur locaux dans la machine virtuelle, mais l’utilisation de VMXNET3 n’est pas présentée comme obligatoire. Il s’agit d’un dépassement de tampon basé sur la pile, c’est-à-dire d’une écriture au-delà des limites d’une zone mémoire allouée sur la pile.

L’exploitation permet d’exécuter du code sur l’hôte avec les privilèges du processus VMX associé à la machine virtuelle. Aucun détail supplémentaire n’est disponible sur le composant vulnérable, les données qui atteignent le tampon ou l’éventuelle nécessité d’une configuration particulière.

Versions vulnérables et mise à jour disponible

Les produits et branches concernés sont les suivants :

Produit	Versions vulnérables indiquées	Version corrective
VMware Workstation	25H2, 26H1	26H1u1
VMware Fusion	25H2, 26H1	26H1u1

Aucun numéro de build correctif plus précis n’a été communiqué. Il n’est pas non plus précisé si Workstation et Fusion utilisent des packages distincts ou des mécanismes de mise à jour différents pour atteindre la version 26H1u1.

Les administrateurs doivent donc vérifier le canal de distribution pris en charge pour chaque installation, sans se limiter au seul nom commercial de la version. Après la mise à jour, il est recommandé de contrôler que le produit indique bien la version corrective attendue.

Broadcom n’a indiqué aucun contournement. Désactiver VMXNET3 pourrait réduire l’exposition à CVE-2026-59346 uniquement, mais cette mesure n’est pas présentée comme une mitigation officielle et ne traite pas CVE-2026-59347. La mesure corrective reste l’installation de la mise à jour.

Le risque augmente lorsque les guests exécutent du code non fiable

Les deux vulnérabilités ne semblent pas directement exploitables à distance sans accès à la machine virtuelle. L’attaquant doit d’abord obtenir des privilèges administrateur locaux dans le guest, ce qui limite la surface d’attaque sans pour autant rendre le risque négligeable.

Les environnements les plus exposés comprennent les laboratoires où sont analysés des fichiers ou programmes non fiables, les postes de développement, les environnements de test partagés et les machines virtuelles utilisées par des personnes autres que l’administrateur de l’hôte. Un malware déjà présent dans le guest pourrait également tenter d’exploiter une seconde vulnérabilité pour atteindre le système sous-jacent.

Les conséquences dépendent des privilèges obtenus sur l’hôte. Dans le cas de CVE-2026-59347, le niveau indiqué est celui du processus VMX. Pour CVE-2026-59346, l’impact est décrit plus largement comme une exécution arbitraire de code sur l’hôte, sans précision supplémentaire sur le contexte de sécurité final.

Une compromission de la frontière guest-hôte peut exposer les données et identifiants présents en dehors de la machine virtuelle, ou permettre de poursuivre les mouvements sur le système. Il s’agit de scénarios potentiels : aucune chaîne d’attaque ni preuve décrivant des compromissions réelles attribuables à ces deux failles n’a été publiée.

Aucune preuve publique d’attaques, mais le précédent du KEV pèse

Broadcom n’a signalé aucune preuve d’exploitation dans la nature de CVE-2026-59346 ou CVE-2026-59347. Les deux vulnérabilités auraient été communiquées au fournisseur de manière privée.

Les deux identifiants ne figurent pas dans l’extrait disponible du catalogue Known Exploited Vulnerabilities de la CISA. Ils ne disposent donc d’aucune date d’ajout ni échéance fédérale de remédiation connue. Cette information ne confirme pas l’absence d’attaques : le contenu consultable ne présente qu’une partie des 26 résultats associés à VMware.

Le contexte du fournisseur appelle néanmoins à la prudence. Plus de deux douzaines de vulnérabilités VMware figurent dans le KEV, qui recense les failles pour lesquelles des preuves d’exploitation existent. Par ailleurs, CVE-2026-59310, attribuée au même fournisseur, a été ajoutée au catalogue le 18 août 2026.

Parmi les précédents directement liés aux produits de virtualisation pour postes de travail figurent trois vulnérabilités ajoutées au KEV le 4 mars 2025, toutes assorties d’une échéance fédérale fixée au 25 mars 2025 :

• CVE-2025-22224, CVSS 9.3, affecte ESXi et Workstation et permet de passer du guest au processus VMX au moyen d’une condition de concurrence TOCTOU ;
• CVE-2025-22225, CVSS 8.2, permet à un attaquant contrôlant le processus VMX d’effectuer une écriture arbitraire dans le noyau ESXi et a été utilisée dans des campagnes de ransomware ;
• CVE-2025-22226, CVSS 7.1, concerne ESXi, Workstation et Fusion et permet de lire la mémoire du processus VMX en exploitant une faille dans HGFS.

D’autres précédents concernent des composants VMware différents. CVE-2024-38812 et CVE-2024-38813, qui touchent vCenter Server, figurent dans le KEV depuis le 20 novembre 2024, avec une échéance fixée au 11 décembre 2024. CVE-2024-37085, un contournement d’authentification dans ESXi utilisé dans des campagnes de ransomware, a été ajoutée le 30 juillet 2024, avec une échéance au 20 août 2024.

Ces cas ne prouvent pas que les deux nouvelles vulnérabilités sont déjà exploitées. Ils montrent toutefois que les failles VMware capables de compromettre l’isolation ou les systèmes de gestion sont effectivement utilisées dans des attaques.

Vérifications à effectuer immédiatement

La première étape consiste à recenser toutes les installations de VMware Workstation et VMware Fusion, y compris celles présentes sur les postes de développement ou les ordinateurs qui ne sont pas gérés de manière centralisée.

Les administrateurs doivent ensuite :

1. identifier les installations en versions 25H2 et 26H1 ;
2. effectuer la mise à jour vers la version 26H1u1 en suivant le processus pris en charge par Broadcom ;
3. vérifier quelles machines virtuelles utilisent des adaptateurs VMXNET3, pertinents pour CVE-2026-59346 ;
4. donner la priorité aux guests dans lesquels des utilisateurs ou des processus administrateur exécutent des logiciels non fiables ;
5. contrôler que la mise à jour a bien été appliquée sur chaque hôte ;
6. intégrer à la remédiation les précédentes vulnérabilités VMware présentes dans le KEV.

Aucun indicateur de compromission spécifique, aucune signature de détection ni procédure d’investigation forensique dédiée n’a été publiée. En l’absence de ces éléments, les contrôles peuvent porter sur les comportements anormaux des processus VMX, les arrêts inattendus des machines virtuelles et les exécutions suspectes sur l’hôte associées à des activités administratives dans le guest. Ces signaux ne prouvent pas une exploitation, mais peuvent justifier une analyse plus approfondie.

La priorité opérationnelle reste simple : lorsque Workstation ou Fusion 25H2 et 26H1 sont installés, il faut passer à 26H1u1. Aucun contournement n’étant disponible, reporter la mise à jour revient à maintenir ouverts les deux chemins d’évasion de la machine virtuelle.