CVE-2025-22224 : évasion de VM dans VMware ESXi par VMCI

Une course TOCTOU dans VMCI, une écriture hors limites dans le processus VMX de l'hôte, et une chaîne de trois failles qui donne l'hyperviseur.

Un admin d'une VM pouvait écrire hors limites dans le processus VMX de l'hôte, grâce à une course TOCTOU dans VMCI. Chaînée à deux autres failles, elle donnait le contrôle de l'hyperviseur ESXi. Elle a été exploitée avant son correctif de mars 2025 : il faut passer en ESXi 8.0 U3d, 8.0 U2d ou 7.0 U3s minimum.

Fiche d'identité

VMCI, un canal direct entre la VM et l'hôte

VMCI est un périphérique PCI virtuel qui offre à la VM un canal rapide vers l'hôte, sans passer par le réseau. VMware Tools et vsock s'en servent, par exemple pour les sauvegardes ou les opérations invitées.

Côté hôte, ce périphérique est émulé par le processus VMX, l'équivalent de QEMU : un processus par VM, sur l'hôte ESXi. La VM lui envoie des messages en écrivant dans ses registres (I/O ou MMIO) et dans des pages de mémoire partagées.

Trois raisons en font une bonne cible :

• il est présent par défaut dans la plupart des VM ;
• son driver invité est accessible à tout admin de la VM, sans interaction de l'hôte ;
• il lit des données que la VM peut modifier à tout moment, ce qui ouvre la porte aux courses.

Le bug : vérifier une valeur, puis la relire

Le VMX vérifie une taille lue dans la mémoire de la VM, puis la relit pour copier les données. Entre les deux lectures, la VM la remplace par une valeur trop grande. C'est un TOCTOU (time-of-check / time-of-use), aussi appelé double fetch.

Broadcom n'a pas publié le code fautif. Le pseudo-code ci-dessous illustre le schéma, il ne reproduit pas le code réel de VMware :

/* Côté hôte, dans le VMX (illustratif) */
struct msg *m = guest_shared_page;          /* mémoire que la VM contrôle */

if (m->len > sizeof(host_buf))              /* 1. CHECK : lecture n°1 */
    return -EINVAL;

memcpy(host_buf, m->data, m->len);          /* 2. USE : lecture n°2 */

L'attaque se déroule ainsi :

1. Un premier vCPU de la VM envoie un message avec len = 64, une taille valide.
2. Le VMX lit len, la vérification passe.
3. Un second vCPU écrit len = 0x10000 dans la même page, juste après la vérification.
4. Le VMX relit len pour la copie et écrit 64 Ko dans un tampon de taille fixe : débordement de tas.
5. Les octets qui débordent viennent de la VM : l'attaquant choisit ce qu'il écrase (pointeurs de fonction, métadonnées du tas). Dans l'attaque analysée par Huntress, l'exploit sauvegarde un pointeur de fonction du VMX, le remplace par l'adresse de son shellcode, puis envoie un message VMCI pour que le VMX l'appelle.

La fenêtre est très courte. L'attaquant relance la course en boucle jusqu'à tomber dedans, ce qui demande au moins deux vCPU.

Le correctif type consiste à lire la valeur une seule fois dans une variable locale, puis à ne plus utiliser que cette copie :

size_t len = READ_ONCE(m->len);             /* une seule lecture */
if (len > sizeof(host_buf))
    return -EINVAL;
memcpy(host_buf, m->data, len);

La chaîne d'évasion

CVE-2025-22224 seule ne suffit pas : il faut d'abord connaître les adresses du VMX, puis sortir de son bac à sable. Les attaquants l'ont donc enchaînée à deux autres failles du même bulletin.

La fuite de mémoire (CVSS 7.1) donne les adresses, le débordement VMCI (9.3) donne le code dans le VMX, et l'écriture dans le noyau (8.2) fait sortir du bac à sable. Sans la troisième faille, l'attaquant reste enfermé dans le processus VMX.

Dans une attaque réelle

En décembre 2025, Huntress a interrompu une intrusion qui utilisait cette chaîne avant sa dernière étape, peut-être un rançongiciel. Les chemins de compilation des binaires (dossier 2024_02_19) laissent penser que l'outil existait dès février 2024, soit un an avant le correctif. Huntress attribue les trois CVE avec une confiance moyenne.

1. Accès initial : un VPN SonicWall compromis, puis un compte administrateur de domaine et des rebonds RDP jusqu'aux contrôleurs de domaine.
2. Préparation dans la VM Windows : l'orchestrateur exploit.exe (surnommé MAESTRO) désactive les périphériques VMCI de l'invité, puis charge un pilote noyau non signé, MyDriver.sys, grâce à l'outil KDU.
3. Évasion : le pilote détecte la version d'ESXi, fait fuiter la mémoire du VMX, la corrompt via VMCI, puis sort du bac à sable vers le noyau.
4. Persistance : une porte dérobée ELF, VSOCKpuppet, s'installe sur l'hôte. Elle écoute sur VSOCK, pas sur le réseau, ce qui la rend invisible aux outils de surveillance réseau classiques.
5. Contrôle : depuis n'importe quelle VM, un client Windows (client.exe) parle à la porte dérobée par VSOCK.

Le nom du dossier de compilation (ESXI_8.0u3) suggère que l'outil visait ESXi 8.0 U3. Des chemins en chinois simplifié et un README en anglais font penser à un outil destiné à être vendu ou partagé.

Patcher

Il n'existe aucun contournement : il faut installer la version corrigée, puis redémarrer l'hôte. Le correctif est dans le VMX, donc une VM qui tourne garde l'ancien code tant qu'elle n'a pas été redémarrée ou déplacée.

Versions corrigées

Fusion 13.x n'est touché que par CVE-2025-22226, corrigée en 13.6.3.

Les branches ESXi 6.5 et 6.7 sont en fin de support : sans contrat de support étendu, la seule option est de migrer en 7.0 ou 8.0.

Procédure sur un hôte ESXi

1. Relever la version actuelle :

   vmware -vl

2. Libérer l'hôte : déplacer les VM par vMotion vers un hôte déjà patché, ou les éteindre proprement.
3. Passer en mode maintenance :

   esxcli system maintenanceMode set --enable true

4. Déposer le bundle hors ligne (.zip téléchargé sur le portail Broadcom) sur un datastore, puis lister ses profils :

   esxcli software sources profile list -d /vmfs/volumes/datastore1/VMware-ESXi-8.0U3d-depot.zip

5. Appliquer le profil -standard (pas -no-tools sauf besoin) :

   esxcli software profile update \
     -d /vmfs/volumes/datastore1/VMware-ESXi-8.0U3d-depot.zip \
     -p ESXi-8.0U3d-<build>-standard

6. Redémarrer l'hôte, vérifier le build avec vmware -vl, puis sortir du mode maintenance :

   esxcli system maintenanceMode set --enable false

7. Passer au suivant. Dans un cluster géré par vCenter, vSphere Lifecycle Manager enchaîne ces étapes hôte par hôte.

Vérifier

• Chaque hôte affiche un build égal ou supérieur à celui du tableau.
• Aucune VM ne tourne encore dans un VMX lancé avant le correctif : toutes ont été redémarrées ou déplacées depuis.
• Workstation : version 17.6.3 ou plus dans Aide > À propos.

Détecter et durcir

Une évasion réussie laisse peu de traces dans la VM : il faut regarder côté hôte.

Quoi surveiller

Huntress publie des règles YARA et Sigma pour cet outil.

Ce qui limite l'impact

• Protéger l'admin des VM : la faille demande d'être admin dans la VM. Un poste compromis en simple utilisateur ne suffit pas.
• Isoler l'administration : interfaces de gestion ESXi et vCenter sur un réseau dédié, jamais exposées aux VM ni à Internet.
• Activer le Secure Boot et le mode execInstalledOnly : l'hôte refuse alors d'exécuter des binaires non signés, ce qui complique la persistance après une évasion.
• Retirer les périphériques inutiles : moins de code émulé exposé à la VM, c'est moins de surface d'attaque.

Références

Le bulletin Broadcom refuse les accès automatisés : sa matrice de correctifs a été vérifiée par des reprises concordantes.

• VMSA-2025-0004, le bulletin Broadcom
• KB 389385, Broadcom : builds 24585383, 24585300 et 24585291
• Reprise de la matrice de correctifs, pbxscience.com : scores, produits, versions
• Fiche CVE-2025-22224, cvefeed.io : CWE-367, dates KEV
• VMware ESXi zero-days likely exploited a year before disclosure, BleepingComputer : résumé du rapport Huntress
• Catalogue KEV de la CISA