Aller au contenu
KLYNLABS

VMware Workstation et Fusion : deux failles critiques permettent de sortir de la VM

Broadcom corrige un débordement d'entier noté 9,3 sur 10 et un débordement de pile dans HGFS, sans aucun contournement possible en attendant la mise à jour.

Kelvyn4 min de lecture

Broadcom a corrigé deux vulnérabilités critiques dans VMware Workstation et VMware Fusion, ses logiciels de virtualisation pour postes de travail. Toutes deux relèvent de la même catégorie, la plus redoutée dans le monde de la virtualisation : l'évasion de machine virtuelle.

Concrètement, un utilisateur disposant de droits d'administration sur une simple machine virtuelle peut exécuter du code sur la machine hôte qui l'héberge — c'est-à-dire sortir du bac à sable censé le contenir, et atteindre le système d'exploitation de l'ordinateur physique.

Pourquoi une évasion de VM est un problème d'une autre nature

Une machine virtuelle est utilisée précisément parce qu'elle est censée être étanche. On y ouvre un fichier suspect, on y teste un logiciel douteux, on y donne un accès administrateur à un étudiant ou à un prestataire, en partant du principe que ce qui se passe dans la VM reste dans la VM. C'est ce postulat qui fonde des usages entiers : analyse de logiciels malveillants, environnements de formation, laboratoires de test, cloisonnement de projets clients.

Une faille d'évasion casse ce postulat. Elle transforme un privilège local dans un environnement jetable en privilège sur la machine réelle — avec tout ce que cela suppose : accès aux fichiers de l'utilisateur, aux autres machines virtuelles hébergées, au réseau de l'entreprise. C'est pour cette raison que ces vulnérabilités sont systématiquement notées très haut.

CVE-2026-59346 : la plus grave des deux, notée 9,3 sur 10

Cette faille est un débordement d'entier lié à l'adaptateur réseau virtuel VMXNET3. Selon l'avis relayé par The Hacker News, un acteur malveillant disposant de privilèges administratifs locaux sur une machine virtuelle équipée de cet adaptateur peut exploiter le problème pour exécuter du code directement sur l'hôte.

Le détail de l'adaptateur compte : VMXNET3 est le pilote réseau paravirtualisé recommandé par VMware pour ses performances, et il est retenu par défaut dans une grande partie des configurations. Ce n'est donc pas un composant exotique que seuls quelques utilisateurs auraient activé. La faille a été signalée par les chercheurs identifiés comme @h4urek, @cameudis et Stan S.

CVE-2026-59347 : le partage de fichiers comme point d'entrée

La seconde vulnérabilité, notée 8,1, est un débordement de pile dans HGFS — le composant qui permet de partager des dossiers entre la machine hôte et la machine virtuelle. Elle permet une exécution de code avec les droits du processus VMX sur l'hôte.

HGFS est la fonction que l'on active pour glisser un fichier du bureau vers la VM sans passer par le réseau. Elle est pratique, largement utilisée, et elle constitue par nature un pont entre les deux mondes que la virtualisation sépare — ce qui en fait une cible logique. Cette faille a été découverte par Yeonghyeon Choi et Tianchu Chen, du Tencent Xuanwu Lab.

Aucun contournement : la mise à jour est la seule réponse

Les versions concernées sont VMware Workstation 25H2 et 26H1, ainsi que VMware Fusion 25H2 et 26H1. Les correctifs sont disponibles dans les versions Workstation 26H1u1 et Fusion 26H1u1.

Broadcom n'indique aucun contournement possible en attendant la mise à jour. C'est une précision importante : dans de nombreux avis de sécurité, l'éditeur propose une mesure d'atténuation temporaire — désactiver un service, fermer un port, restreindre un droit. Ici, il n'y en a pas. Désactiver HGFS réduirait la surface d'attaque de la seconde faille, mais ne fait rien contre la première, qui passe par un adaptateur réseau difficilement supprimable en pratique.

Qui doit s'inquiéter en priorité

  • Les environnements où plusieurs personnes disposent de droits administrateur sur des VM différentes hébergées sur la même machine : postes de formation, laboratoires, salles de TP.

  • Les analystes qui exécutent des échantillons de logiciels malveillants dans une machine virtuelle sur leur poste de travail habituel.

  • Les prestataires et développeurs à qui l'on confie une VM avec des droits élevés sur un poste partagé ou appartenant à un client.

À l'inverse, un utilisateur qui exécute seul, sur son propre ordinateur, une machine virtuelle dont il est déjà administrateur de l'hôte n'ajoute pas de risque significatif : l'attaquant aurait déjà besoin d'un accès administrateur dans la VM pour exploiter la faille.

Exploitée ou théorique ? La distinction compte

Aucune exploitation active n'est documentée à ce jour. Il s'agit de vulnérabilités signalées par des chercheurs et corrigées par l'éditeur, pas d'attaques observées dans la nature. La différence est réelle, et elle doit se traduire dans la façon de prioriser : ce n'est pas une urgence de type « tout arrêter maintenant ».

Cela dit, l'absence de contournement et la publication d'un avis détaillé raccourcissent la fenêtre. Un avis public décrivant le composant affecté est un point de départ pour qui cherche à reconstituer l'exploit — et c'est précisément la tâche que les modèles d'IA sont désormais capables d'automatiser, comme l'illustre le score obtenu par GPT-6 Astra sur ExploitBench.

Source

The Hacker News — « Critical VMware Workstation and Fusion Flaw Lets VM Admins Execute Host Code »

À lire ensuite