Un chercheur publiant sous le pseudonyme 0xCyberstan a rendu public un code d’exploitation pour la faille CVE-2026-59346 affectant l’adaptateur virtuel VMXNET3 de VMware. Broadcom a corrigé la vulnérabilité le 3 septembre 2026 dans VMware Workstation et Fusion 26H1u1. Le proof of concept (PoC) provoque un plantage du processus hôte vmware-vmx depuis une machine invitée, sans pour autant exécuter de code sur l’hôte.
VMXNET3 et mécanisme de la vulnérabilité
La vulnérabilité, notée 9,3 sur CVSSv3 par Broadcom, est une erreur d’entier (integer overflow) située dans le traitement TCP Segmentation Offload (TSO) du chemin VMXNET3. Le calcul de la taille du tampon multiplie en 32 bits le nombre de segments par l’espace requis par segment. Si le produit est suffisamment grand, il déborde (wrap) et la taille allouée devient trop petite. La boucle de copie continue sur le nombre de segments initial, entraînant un débordement mémoire au-delà de l’allocation heap.
Ce chemin TSO est exécuté dans le processus vmware-vmx de l’hôte, pas dans la machine invitée. Un correctif antérieur (CVE-2025-41236) bornait chaque champ individuel et leur somme à 9 216, mais ne vérifiait pas le produit final : des entrées qui franchissent toutes les limites peuvent encore provoquer un overflow.
PoC public : comportement et limites
Le code publié fonctionne comme un module noyau Linux et requiert des privilèges administrateur dans la machine invitée. Il écrit directement des descripteurs de transmission dans l’anneau VMXNET3, court-circuite les contrôles TSO du pilote invité, puis déclenche la doorbell mémoire-mappée de l’adaptateur pour que l’hôte traite les descripteurs. L’écriture hors bornes atteint une zone mémoire non mappée, provoquant un segfault de vmware-vmx et l’extinction de la VM.
Le dépôt indique explicitement qu’il ne tente pas d’exécution de code sur l’hôte et avertit que les tests peuvent effacer l’état non sauvegardé de la machine invitée. Le laboratoire documenté dans le dépôt utilisait VMware Workstation Pro 25.0.1 sur un hôte Ubuntu avec une VM Alpine. Le code est disponible publiquement sur GitHub, offrant aux équipes de défense un cas de reproduction concret tout en fournissant aux attaquants un point de départ pour de possibles développements ultérieurs.
Impact, signalement et évaluations
Broadcom liste les versions Workstation et Fusion 25H2 et 26H1 comme affectées et ne propose aucun contournement. Trend Micro’s Zero Day Initiative référence la faille sous ZDI-26-647 : le bug a été signalé à Broadcom le 28 août et l’avis ZDI a été publié le 9 septembre 2026. ZDI indique qu’une exécution arbitraire de code dans le contexte de l’hyperviseur est possible en théorie, mais qu’elle exige d’abord une exécution de code à privilèges élevés dans la machine invitée. ZDI a attribué une note de 7,5, inférieure à l’évaluation 9,3 de Broadcom. Quoi qu’il en soit, le PoC public montre pour l’instant une corruption mémoire et un crash, et non une prise de contrôle avérée de l’hôte.
Qui doit agir et quelles mesures prendre
Les hôtes exécutant des invités non fiables ou semi-fiables présentent le risque le plus élevé, puisque l’attaque nécessite des droits administrateur dans la VM. Broadcom encadre la correction principale par la mise à jour de l’hôte vers 26H1u1. Les étapes concrètes recommandées par la source sont les suivantes :
– Mettre à jour Workstation ou Fusion sur l’hôte vers 26H1u1 ou une version ultérieure prise en charge.
– Vérifier la version du produit sur l’hôte directement, car les mises à jour du système invité ne corrigent pas ce code vulnérable.
– Restreindre les accès administrateur à l’intérieur des machines invitées, requis par l’exploit.
– Examiner si des VMs sensibles ont réellement besoin de l’adaptateur VMXNET3.
La source rappelle que quiconque reproduit le crash doit le faire uniquement dans un laboratoire isolé et autorisé, l’objectif étant de vérifier l’état des correctifs plutôt que d’exploiter des systèmes en production.
