Exploits de gestion connus

vCenter regroupe de nombreux services derrière son front end web, et plusieurs ont porté de l'exécution de code à distance pré-authentification : les plugins de santé vSAN et autres, les chemins vmdir et vmca basés sur DCERPC, et des failles d'upload de fichiers et de désérialisation dans des composants groupés. Faire correspondre un build vCenter au service affecté donne une voie directe et non authentifiée vers le root de l'appliance.

2 min de lecturemis à jour le 13 oct. 2026florianamette1 contributeur
Demander à votre assistant (MCP)Modifier sur GitHub

vCenter est une appliance exécutant de nombreux services groupés derrière son front end HTTPS, et cette étendue en a fait une source répétée d'exécution de code à distance pré-authentification. Le motif est un endpoint accessible d'un composant groupé, un plugin du client vSphere, un service d'annuaire ou de certificats, une fonctionnalité d'upload ou de reporting, qui manipule incorrectement l'entrée avant l'authentification, donnant l'exécution de code en tant que compte de service ou root sur l'appliance. Parce que vCenter contrôle tout le périmètre, le root de l'appliance est une compromission totale.

Les grappes récurrentes :

  • Plugins du client vSphere (par exemple le service de santé vSAN) : endpoints accessibles pré-auth ayant conduit à l'exécution de code à distance.
  • Services d'annuaire et de certificats (vmdir, vmca) accessibles via leurs interfaces RPC/LDAP avec des failles d'authentification ou de sûreté mémoire.
  • Upload de fichiers et gestion des chemins dans les fonctionnalités groupées de reporting et de support-bundle, donnant l'écriture arbitraire de fichiers puis l'exécution.
  • Désérialisation dans les composants groupés basés sur Java, une voie classique vers l'exécution de code.

Exploiter le motif#

bash
# fingerprint the exact build (decides which service is vulnerable)
curl -sk https://<vcenter>/sdk/vimServiceVersions.xml
# enumerate which bundled endpoints are reachable
curl -sk https://<vcenter>/ui/h5-vsan/rest/proxy/service/   # example plugin path
curl -sk https://<vcenter>:5480/                            # VAMI
# match the build to the advisory for the reachable service, then use its PoC

Une approche fonctionnelle consiste à identifier le build, énumérer quels endpoints groupés répondent, et faire correspondre à l'avis pour ce service. Beaucoup sont non authentifiés, donc atteindre l'endpoint est souvent la seule condition préalable.

Notes d'exploitation#

  • La chaîne de build est décisive : les avis vCenter nomment les versions exactes affectées et le service, donc l'empreinte mappe directement à un exploit utilisable.
  • Une RCE pré-auth dans un service groupé donne l'exécution sur l'appliance, qui déverrouille ensuite le matériel de clés de l'abus du SSO et des tokens et vpxuser, se propageant en cascade vers chaque hôte.
  • Les vCenter exposés sur Internet ou le réseau de gestion avec des niveaux de correctifs en retard sont à forte valeur et ont alimenté des intrusions à grande échelle ; l'exposition plus un build correspondant constituent toute la chaîne.

Références#