Xen Orchestra : une faille d’authentification exploitée donne les droits d’administrateur sur la virtualisation XCP-ng

Veille cyber Top-Secured : analyse indépendante fondée sur les sources citées plus bas. Top-Secured n'est pas affilié aux entreprises mentionnées et ne vous demandera jamais vos identifiants bancaires ni vos mots de passe.

Vates a corrigé une faille critique dans Xen Orchestra, la console web qui pilote les hôtes XCP-ng, et signale qu’elle est déjà exploitée. Un cookie piégé suffit pour se faire passer, sans mot de passe, pour un utilisateur existant, en général un administrateur. Les versions 6.9.2 et 6.10.1 la corrigent ; les consoles exposées doivent aussi être inspectées.

Les faits

Le 10 novembre 2026, l’éditeur français Vates, à l’origine de Xen Orchestra et de XCP-ng, a publié l’avis VSA-2026-062, classé critique, en précisant que la faille est activement exploitée. Aucun identifiant CVE ni score CVSS n’était attribué à la publication. Les versions corrigées sont sorties le jour même.

Le défaut se trouve dans l’authentification de l’API REST. Un cookie dont le jeton est un objet vide fabriqué, et non une chaîne de caractères, arrive tel quel à la recherche de jetons. Celle-ci renvoie alors le premier jeton valide enregistré par Xen Orchestra, et la requête est traitée comme si elle venait de son propriétaire. L’attaquant peut ensuite lister des jetons de connexion réutilisables et agir avec les droits d’administrateur. Le correctif, intégré sur GitHub, refuse tout jeton qui n’est pas une chaîne non vide.

Qui est concerné

Toutes les installations de Xen Orchestra antérieures à 6.9.2 (canal stable) et 6.10.1 (canal latest), qu’il s’agisse de l’appliance XOA ou d’une version compilée depuis les sources. Selon Vates, la prise de contrôle de la console peut mener à l’exécution de code sur les pools gérés et à un accès root aux hôtes XCP-ng. Les consoles joignables depuis Internet sont en première ligne.

Que faire maintenant

1. Mettez à jour : XOA en 6.9.2 (stable) ou 6.10.1 (latest), soit xo-server 5.211.2 ou 5.213.1 ; pour une installation depuis les sources, dernier commit de master puis recompilation.
2. Retirez la console d’Internet : réseau d’administration dédié ou VPN uniquement.
3. Filtrez : bloquez les adresses IP et l’adresse Tor listées dans l’avis et, sur votre reverse proxy, les requêtes dont le cookie authenticationToken commence par j:. Vates prévient que d’autres encodages peuvent contourner ce type de règle.
4. Cherchez des traces : une attaque réussie ne laisse rien dans le journal d’authentification. Repérez une VM nommée pivot2, puis sur chaque hôte XCP-ng lancez xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', zgrep -- '-serial file:' /var/log/xensource.log* et ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*.
5. En cas de compromission : changez tous les secrets connus de la plateforme (comptes root, secret de pool, dépôts de sauvegarde, proxys, utilisateurs, secrets OTP, serveur mail) et, comme le recommande Vates, réinstallez plutôt que de nettoyer.

Notre analyse

La console d’un hyperviseur détient les clés de toutes les machines virtuelles : c’est le serveur le plus sensible de l’entreprise, et il n’a rien à faire sur Internet. Corriger ne suffit pas cette fois : faute de trace de connexion, seule une vérification des hôtes dira si quelqu’un est déjà passé.

Sources

• Vates — VSA-2026-062: Empty-object login token
• GitHub (vatesfr/xen-orchestra) — fix(xo-server): validate authentication token IDs, PR #10748
• The Hacker News — Hackers Exploit Critical Xen Orchestra Auth Bypass Flaw to Gain Admin Access

Comment nous choisissons, vérifions et rédigeons nos analyses →