Xen Orchestra : cette faille critique déjà exploitée permet de compromettre les hôtes XCP-ng

Une faille de sécurité critique, déjà exploitée, peut mener à la compromission complète des hôtes XCP-ng. Voici ce que l'on sait sur cette vulnérabilité qui menace les infrastructures de virtualisation.

Pour rappel, Xen Orchestra est l'interface web développée par l'éditeur français Vates pour administrer les environnements XCP-ng : hôtes, pools, machines virtuelles, sauvegardes... Autrement dit, c'est la console qui a la main sur toute l'infrastructure de virtualisation. Le duo XCP-ng et Xen Orchestra fait partie des solutions que j'avais évoquées il y a quelque temps dans mon article sur les alternatives à l'hyperviseur VMware ESXi.

Le 10 novembre 2026, Vates a publié un bulletin de sécurité pour évoquer une faille de sécurité critique découverte dans Xen Orchestra et l'appliance officielle XOA (Xen Orchestra Appliance). Pour le moment, cette vulnérabilité n'a ni identifiant CVE, ni score CVSS. Pour autant, elle mérite notre attention.

Un jeton vide qui donne les droits d'administration

Le problème se situe dans l'API REST de Xen Orchestra, au niveau du traitement du cookie authenticationToken. Si un attaquant envoie la valeur j:{} (ou sa forme encodée j:%7B%7D), le serveur y voit du JSON à cause du préfixe j: et la convertit en objet vide, au lieu de la traiter comme une chaîne de caractère. Cet objet est transmis tel quel au composant chargé de retrouver le jeton.

Sans critère de recherche, c'est le premier jeton de la base qui est renvoyé. S'il n'a pas expiré, la requête est authentifiée au nom de son propriétaire, avec ses droits (donc potentiellement un admin). L'attaquant peut ensuite interroger la route /rest/v0/users/me/authentication_tokens pour récupérer des identifiants de jetons réutilisables, et donc conserver son accès.

Vates évoque des actions effectuées avec le privilège Admin, de l'exécution de code arbitraire sur les pools gérés et "une prise de contrôle complète d'un nœud XCP-ng en tant que root", peut-on lire.

Surtout, ce qui est problématique, c'est que cette faille est activement exploitée par un cybercriminel (associé notamment à l'adresse IP 91.211.251.112). Mais en regardant le bulletin de sécurité de Vates, on ne trouve pas une adresse IP, mais 8 actuellement, ainsi qu'un service .onion (réseau Tor). Autrement dit, la liste semble s'étoffer avec le temps.

Vates recommande d'installer le correctif dès que possible et liste plusieurs mesures complémentaires :

• Mettre à jour Xen Orchestra : passer sur XOA 6.10.1 (canal latest) ou 6.9.2 (canal stable). Le correctif correspond à xo-server, le composant serveur de Xen Orchestra, en version 5.213.1 et 5.211.2.

• Ne pas exposer Xen Orchestra sur Internet : l'instance doit être placée sur un réseau d'administration dédié. Cela peut sembler évident, mais il faut toujours le rappeler.

• Bloquer l'infrastructure de l'attaquant : filtrer les flux en provenance et à destination des huit adresses IP listées dans le bulletin, et bloquer le trafic Tor vers l'adresse en .onion indiquée

• Filtrer le jeton vide : si vous ne pouvez pas mettre à jour immédiatement, ajoutez une règle sur le WAF ou le reverse proxy pour bloquer les deux formes du cookie malveillant.

Comment savoir si votre serveur est compromis ? Vates prévient qu'aucun journal ne permet de détecter l'accès non authentifié. Il faut donc chercher les traces laissées ensuite. Dans Xen Orchestra, une machine virtuelle nommée pivot2. Sur les hôtes XCP-ng, les fichiers /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 et /.ustar6, un fichier /etc/ld.so.preload, constituent des traces de compromission. Il y a aussi des cas où il y a une VM dont le port série est redirigé vers un fichier (paramètre hvm_serial: file, également visible dans xensource.log). Je ne vais pas trop rentrer dans les détails ici, car le bulletin publié par Vates fournit les commandes pour vous aider.

Une seconde faille, sans correctif pour le moment

Le même jour, Vates a publié un second bulletin, considéré cette fois-ci comme important. Il concerne l'import de machines virtuelles : Xen Orchestra transmet le fichier à l'hôte sans en contrôler le contenu, ce qui permet d'y glisser des paramètres piégés, dont hvm_serial. Vates indique que l'attaquant a utilisé ce mécanisme avec le privilège Admin, en renvoyant vers la première faille. Il y a donc des cyberattaques où ces deux vulnérabilités sont exploitées conjointement.

Xen Orchestra 6.10.1 et les versions antérieures sont affectées, et aucun correctif n'était disponible à la date du bulletin. En attendant, Vates recommande de réserver l'import de VM aux administrateurs. À surveiller de très près si vous utilisez cette solution pour appliquer les patchs dès que possible.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.