Broadcom (VMware) a publié une mise à jour de son avis de sécurité VMSA-2024-0012.1 contenant une note particulièrement importante pour les équipes d’infrastructure : des signes d’exploitation active dans la nature (in the wild) du CVE-2024-37079, l’une des vulnérabilités critiques affectant VMware vCenter Server. La date de mise à jour de l’avis est fixée au 23 janvier 2026, ce qui envoie un message clair : appliquer le patch n’est plus une recommandation, c’est une priorité opérationnelle.

Le rapport regroupe trois CVE : deux vulnérabilités de débordement de heap dans l’implémentation du protocole DCERPC (associes à une exécution de code à distance potentielle) et une vulnérabilité d’élévation de privilèges locale due à une mauvaise configuration de sudo.

Ce qui a été publié précisément

Du point de vue technique et impact, l’avis couvre :

• CVE-2024-37079 et CVE-2024-37080 (Critiques, CVSS 9,8) :
  Vulnérabilités de débordement de heap dans DCERPC. Un acteur ayant un accès réseau pourrait les exploiter par le biais de paquets spécialement conçus, avec un risque de RCE (selon l’évaluation du fabricant).
• CVE-2024-37081 (Important/Critique dans l’avis, CVSS 7,8) :
  Escalade de privilèges locale : un utilisateur authentifié localement sans privilèges administratifs pourrait obtenir les droits de root sur l’appliance vCenter Server.

De plus, la mise à jour du 23 janvier 2026 ajoute une remarque modifiant le contexte de risque : « Broadcom dispose d’informations suggérant que l’exploitation du CVE-2024-37079 a eu lieu dans la nature ».

En signe supplémentaire de la criticité opérationnelle, le registre du NVD indique que CVE-2024-37079 a été ajouté au catalogue CISA KEV avec une date limite de remédiation fixée au 23 janvier 2026.

Tableau 1 — Résumé exécutif (l’essentiel)

Tableau 2 — Versions corrigées (matrice de réponse du fabricant)

Pourquoi cette situation est-elle particulièrement critique pour vCenter ?

vCenter est souvent considéré comme le centre de contrôle de l’environnement virtualisé : gestion de l’inventaire, des droits, de l’approvisionnement, des réseaux virtuels, du stockage et des opérations. Cela signifie que, même si le problème “n’affecte” qu’un composant, l’impact potentiel est souvent plus important que pour d’autres services : une panne ou une prise de contrôle peut entraîner une perte de contrôle opérationnel, des interruptions de service et un mouvement latéral.

La clé réside dans la combinaison des facteurs clairement identifiés dans l’avis :

• Vecteur d’attaque réseau (pour les CVE critiques DCERPC)
• Sévérité critique (9,8)
• Signes d’exploitation active (au moins pour CVE-2024-37079)

Ce que doivent faire en priorité les équipes systèmes

1. Inventaire immédiat
   • Identifier tous les vCenter et environnements Cloud Foundation (y compris DR/BCP et laboratoires connectés au réseau d’entreprise).
2. Prioriser en fonction de l’exposition
   • Alerter si une route réseau inutile vers vCenter existe (segmentation, ACL, bastion, VPN, saut administré). Même si l’avis évoque “l’accès réseau”, la pratique recommandée est de traiter vCenter comme un service réservé à la gestion.
3. Appliquer le patch approprié
   • vCenter 8.0 → U2d (ou U1e si cela correspond à votre version / cas)
   • vCenter 7.0 → U3r
   • Cloud Foundation 4.x/5.x → KB88287
4. Vérification après intervention
   • Confirmer la version et l’état des services, et examiner les logs d’intégrité et de fonctionnement.
   • Maintenir une surveillance renforcée après le correctif, car les tentatives d’exploitation ont tendance à s’intensifier après la diffusion.
5. Réduire le risque opérationnel
   • Vérifier les accès privilégiés à VCSA, mettre en place une authentification multi-facteur (MFA) là où c’est possible, et renforcer la sécurité du plan de gestion.
   • Aligner ces actions avec vos procédures internes de gestion des vulnérabilités (SLA critique).