CVE-2026-59346 exécute du code sur l’hôte depuis une VM VMware Workstation ou Fusion
Broadcom corrige deux failles dans VMware Workstation et Fusion : CVE-2026-59346 (CVSS 9.3) et CVE-2026-59347 permettent à un administrateur de machine virtuelle d’exécuter du code sur la machine hôte. Mettez à jour vers 26H1u1 sans attendre, car aucun contournement n’existe.
5 septembre 2026. Broadcom corrige deux failles dans VMware Workstation et VMware Fusion. CVE-2026-59346 culmine à CVSS 9.3 ; CVE-2026-59347 à CVSS 8.1. Les deux partent du même postulat : un attaquant qui possède déjà des privilèges administrateur à l’intérieur d’une machine virtuelle peut en sortir pour exécuter du code sur la machine hôte. Pourquoi c’est important : cette frontière entre l’invité et l’hôte est précisément ce qu’un hyperviseur de bureau est censé garantir.
Deux failles, un même contrat rompu
CVE-2026-59346 est un débordement d’entier (integer overflow). Un acteur malveillant disposant de privilèges administratifs locaux sur une machine virtuelle équipée d’un adaptateur réseau virtuel VMXNET3 peut l’exploiter pour exécuter du code sur l’hôte. Le débordement touche le chemin réseau du data plane — l’adaptateur VMXNET3 est l’interface virtuelle par défaut des VM modernes sous VMware. Les chercheurs @h4urek, @cameudis et Stan S sont crédités pour la découverte.
CVE-2026-59347 est un débordement de tampon dans la pile (stack-based buffer overflow) dans HGFS, le Host-Guest File System — la brique qui alimente les dossiers partagés et le glisser-déposer entre l’hôte et l’invité. Exploitée, elle permet d’exécuter du code en tant que processus VMX de la machine virtuelle, c’est-à-dire avec les privilèges du processus qui orchestre la VM côté hôte. Yeonghyeon Choi et Tianchu Chen du Tencent Xuanwu Lab sont crédités.
Les deux failles touchent VMware Workstation et VMware Fusion en versions 25H2 et 26H1. Broadcom est catégorique : il n’existe aucun contournement. Le correctif est livré dans Workstation 26H1u1 et Fusion 26H1u1. Autrement dit, les utilisateurs de la branche 25H2 n’ont pas de correctif dédié : ils doivent migrer vers 26H1u1, ce qui fait de cette mise à jour une montée de version à planifier — avec sauvegarde des machines virtuelles et fenêtre de maintenance — plutôt qu’un simple patch à appliquer en silence.
La précondition qui change la lecture du CVSS
Un CVSS 9.3 qui exige un accès local avec privilèges élevés mérite d’être lu avec attention. L’attaquant ne gagne pas la VM par cette faille : il la possède déjà. Ce que CVE-2026-59346 et CVE-2026-59347 offrent, c’est la sortie — l’escalade de la machine virtuelle vers la machine hôte, puis de l’hôte vers le reste du poste, des autres VM et du réseau d’entreprise.
C’est précisément le scénario redouté dans les parcs de développeurs. Un poste de développement fait tourner des VM avec des droits administrateur locaux par défaut, des dossiers partagés HGFS activés pour la productivité, et souvent des clés d’accès au code source montées à l’intérieur. Le compromis initial — par phishing, par une configuration faible ou par un autre bogue — n’est plus un mur d’arrêt mais un simple préalable. Broadcom le rappelle d’ailleurs : ces privilèges s’obtiennent « par une compromission distincte, via le phishing ou l’exploitation de configurations utilisateur faibles ».
VMXNET3 et HGFS, les deux portes de sortie
Il n’y a rien de hasardeux dans le choix de ces deux surfaces. VMXNET3 est l’adaptateur réseau paravirtualisé que VMware recommande pour ses machines virtuelles : il échange les paquets directement entre l’invité et l’hôte, en court-circuitant une partie des couches d’émulation. C’est un chemin de code performant, mais aussi un chemin profond — un débordement y atteint des structures de l’hôte que le réseau invité ne devrait jamais toucher.
HGFS, de son côté, est la brique des dossiers partagés : elle laisse un invité lire et écrire dans des répertoires de l’hôte. C’est une frontière qui, par nature, traverse la ligne entre les deux mondes. Un débordement de tampon dans ce composant ne frappe pas un périphérique isolé, mais le mécanisme même qui autorise l’invité à s’approcher de l’hôte.
Le résultat est identique dans les deux cas : l’exécution de code côté hôte, directement ou via le processus VMX — le processus qui orchestre la machine virtuelle et porte ses privilèges. Exécuter du code en tant que VMX, c’est franchir la quasi-totalité du chemin vers la compromission complète de la machine.
En pratique, une évasion ne sert d’ailleurs pas qu’à « casser » la machine hôte. Elle sert surtout de pivot : une fois sur l’hôte, l’attaquant atteint les autres VM qui y tournent, les identifiants stockés dans les outils du développeur, et de là le réseau interne. Sur un poste de développement, la machine hôte est souvent jointe au domaine d’entreprise et porte des accès VPN ou SSH vers la production. L’évasion transforme un incident localisé en compromission latérale — c’est précisément ce que CVE-2026-59346 et CVE-2026-59347 rendent possible.
Pourquoi les produits VMware restent des aimants à attaques
VMware demeure une cible de choix. Le mois dernier, des attaquants ont exploité activement deux failles de vCenter, CVE-2026-59309 et CVE-2026-59310, la seconde étant suspectée d’être armée par un APT lié à la Chine. Check Point a dénombré 361 adresses IP victimes dans 47 pays, l’activité ayant commencé cinq jours après la divulgation publique.
La différence ici tient au périmètre. Workstation et Fusion sont des hyperviseurs de type 2 — des logiciels de bureau, pas les piliers du data center que sont vCenter et ESXi. Mais le modèle de confiance est le même, et il s’applique à un parc bien plus vaste : chaque machine de développement devient une surface d’attaque potentielle dès lors qu’elle héberge des VM privilégiées.
Ce qu’il faut faire
- Mettre à jour immédiatement. Appliquer Workstation 26H1u1 ou Fusion 26H1u1. Aucun contournement n’existe, donc il n’y a rien à configurer pour « atténuer » en attendant.
- Traiter le poste hôte comme une cible. C’est lui qui porte le risque résiduel quand la VM est compromise : durcissez-le, segmentez le réseau des VM, et limitez les droits administrateur accordés aux machines virtuelles.
- Auditer les dossiers partagés. HGFS est au cœur de CVE-2026-59347 : désactivez les dossiers partagés et le glisser-déposer là où ils ne sont pas indispensables.
Ces trois gestes ne protègent pas que de ces deux CVE : ils réduisent la surface de toute la classe des failles d’évasion de VM.
Le paradoxe est là : on durcit les serveurs et on patche vCenter, mais on oublie souvent que le poste du développeur — avec sa pile de VM locales — est lui aussi un maillon d’infrastructure. CVE-2026-59346 et CVE-2026-59347 le rappellent au moment où ces postes sont plus connectés que jamais à la production.
Verdict
Si vous faites tourner des VM sous VMware Workstation ou Fusion, mettez à jour vers 26H1u1 immédiatement — les deux failles n’ont aucun contournement, et la précondition d’exploitation (un administrateur dans la VM) est banale sur un poste de développement.
Si vous maintenez un parc de postes de développement, durcissez la machine hôte et coupez les dossiers partagés HGFS inutiles : c’est là que se joue le risque résiduel une fois la VM compromise.
Si vos VM sont éphémères, privilégiez des sandbox ou un hyperviseur de type 1 sur un hôte dédié plutôt qu’un hyperviseur de bureau partagé entre plusieurs usages.