Contournement d'authentification dans Xen Orchestra : accès administrateur et prise de contrôle possible des hôtes XCP-ng

Ce qui s'est passé

Le 10 novembre 2026, Vates a publié l'avis de sécurité VSA-2026-062 concernant un contournement d'authentification critique dans Xen Orchestra. Xen Orchestra est l'interface de gestion web des environnements de virtualisation XCP-ng. Aucun identifiant CVE ni score CVSS n'a encore été attribué.

La faille se situe dans la manière dont l'API REST traite le cookie de connexion. Un cookie dont la valeur est authenticationToken=j:%7B%7D est analysé en un objet vide ({}). Cet objet est transmis à la vérification du jeton sans contrôle préalable qu'il s'agit d'une chaîne de caractères. La recherche du jeton renvoie alors le premier jeton enregistré, et la requête est authentifiée comme étant celle du propriétaire de ce jeton, tant que le jeton n'a pas expiré. Par l'intermédiaire du point d'accès /rest/v0/users/me/authentication_tokens, un attaquant peut ensuite lire des identifiants de jetons de connexion réutilisables.

Selon Vates, un attaquant peut ainsi effectuer des actions avec les privilèges Admin dans Xen Orchestra sans identifiants. Cela peut conduire à l'exécution de code arbitraire sur les pools gérés et à une prise de contrôle complète des hôtes XCP-ng avec les droits root.

Vates indique que la vulnérabilité est activement exploitée par un acteur malveillant opérant depuis 91.211.251.112:8001 et depuis une adresse Tor (voir ci-dessous). On ne sait pas quand les attaques ont commencé ni si la faille a été exploitée avant la publication du correctif. La faille a été découverte par Filip Magic et Christoffer Olsen de TDC NET Security.

Systèmes concernés

• Xen Orchestra antérieur à 6.9.1 (canal stable) et antérieur à 6.10.0 (canal latest)
• les paquets xo-server correspondants antérieurs à 5.211.2 (stable) et 5.213.1 (latest)
• Xen Orchestra Appliance (XOA)

L'attaquant doit avoir un accès réseau à l'interface web de Xen Orchestra. Les instances accessibles depuis Internet présentent le risque le plus élevé. Les hôtes XCP-ng sont également exposés, car Xen Orchestra les gère. Si vous n'utilisez pas Xen Orchestra, cet avis ne vous concerne pas.

Actions à mener immédiatement

1. Mettez à jour Xen Orchestra. Installez Xen Orchestra 6.9.1 sur le canal stable ou 6.10.0 sur le canal latest. Ces versions incluent xo-server 5.211.2 (stable) ou 5.213.1 (latest). Sauvegardez d'abord la configuration de Xen Orchestra. Après la mise à jour, vérifiez que xo-server fonctionne et que vous pouvez vous connecter et voir vos pools.
2. Restreignez l'accès. N'exposez pas Xen Orchestra sur Internet. Vates recommande de le placer sur un réseau de gestion dédié, accessible uniquement aux administrateurs, par exemple via un VPN.
3. Bloquez l'infrastructure de l'attaquant. Vates recommande des règles de filtrage entrant et sortant pour 91.211.251.112 ainsi que le blocage du trafic Tor, afin que les hôtes ne puissent pas atteindre ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. Si vous ne pouvez pas mettre à jour immédiatement, bloquez le jeton vide dans un WAF ou un reverse proxy placé devant Xen Orchestra. Recherchez les motifs de cookie authenticationToken=j:{} et authenticationToken=j:%7B%7D.
5. Recherchez une compromission (voir la section suivante). Si vous trouvez des signes de compromission, renouvelez tous les mots de passe et secrets utilisés dans vos environnements Xen Orchestra et XCP-ng, puis examinez les hôtes et les VM concernés.

Comment vérifier si vous êtes concerné

Vérifiez d'abord la version de Xen Orchestra dans l'interface web ou sur l'appliance. Si elle est antérieure à 6.9.1 (stable) ou 6.10.0 (latest), le système est vulnérable.

Vates et les rapports publiés répertorient les indicateurs de compromission suivants pour la campagne d'attaque connue :

• des requêtes HTTP contenant authenticationToken=j:%7B%7D ou authenticationToken=j:{}
• des connexions vers 91.211.251.112:8001 ou ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• une machine virtuelle nommée pivot2
• des machines virtuelles configurées avec hvm_serial: file
• les fichiers /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 et /.ustar6

Sur les hôtes XCP-ng, exécutez les vérifications recommandées par Vates :

xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file'

zgrep -- '-serial file:' /var/log/xensource.log*

ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*

Recherchez également une VM nommée pivot2, par exemple avec xe vm-list name-label=pivot2.

Selon les rapports, Xen Orchestra n'enregistre pas le cookie forgé. Vous ne pouvez le détecter que par une surveillance HTTP, par exemple dans les journaux d'accès d'un reverse proxy placé devant Xen Orchestra. Vérifiez ces journaux ainsi que les journaux de votre pare-feu pour rechercher les motifs de cookie et les adresses indiquées ci-dessus. Vates précise que ces indicateurs correspondent à une campagne connue. D'autres attaquants peuvent laisser des traces différentes ; l'absence de ces indicateurs ne prouve donc pas qu'un système est sain.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/hackers-exploit-critical-xen-orchestra.html