Bypass di autenticazione in Xen Orchestra: accesso amministrativo e possibile compromissione degli host XCP-ng

Cosa è successo

Il 10 novembre 2026 Vates ha pubblicato l'avviso di sicurezza VSA-2026-062 relativo a un bypass critico dell'autenticazione in Xen Orchestra. Xen Orchestra è l'interfaccia di gestione web per gli ambienti di virtualizzazione XCP-ng. Non è ancora stato assegnato alcun ID CVE né un punteggio CVSS.

Il difetto riguarda il modo in cui la REST API gestisce il cookie di login. Un cookie con valore authenticationToken=j:%7B%7D viene interpretato come un oggetto vuoto ({}). Tale oggetto viene passato al controllo del token senza verificare che sia una stringa. La ricerca del token restituisce quindi il primo token memorizzato, e la richiesta viene autenticata come proprietario di quel token, purché il token non sia scaduto. Tramite l'endpoint /rest/v0/users/me/authentication_tokens, un aggressore può poi leggere ID di token di accesso riutilizzabili.

Secondo Vates, un aggressore può usare questo difetto per eseguire operazioni con privilegi di amministratore in Xen Orchestra senza credenziali. Ciò può portare all'esecuzione arbitraria di codice sui pool gestiti e alla piena compromissione degli host XCP-ng con privilegi root.

Vates riferisce che la vulnerabilità è attivamente sfruttata da un attore di minaccia che opera da 91.211.251.112:8001 e da un indirizzo Tor (vedi sotto). Non è noto quando siano iniziati gli attacchi né se la falla fosse già stata sfruttata prima del rilascio della correzione. La falla è stata scoperta da Filip Magic e Christoffer Olsen di TDC NET Security.

Chi è interessato

• Xen Orchestra precedente alla 6.9.1 (canale stable) e alla 6.10.0 (canale latest)
• i pacchetti xo-server corrispondenti precedenti alla 5.211.2 (stable) e alla 5.213.1 (latest)
• Xen Orchestra Appliance (XOA)

L'aggressore necessita di accesso di rete all'interfaccia web di Xen Orchestra. Le istanze raggiungibili da Internet sono a rischio massimo. Anche gli host XCP-ng sono a rischio, perché Xen Orchestra li gestisce. Se non utilizza Xen Orchestra, questo avviso non La riguarda.

Cosa fare ora

1. Aggiorni Xen Orchestra. Installi Xen Orchestra 6.9.1 sul canale stable oppure 6.10.0 sul canale latest. Includono xo-server 5.211.2 (stable) o 5.213.1 (latest). Esegua prima un backup della configurazione di Xen Orchestra. Dopo l'aggiornamento, verifichi che xo-server sia in esecuzione e che Lei possa accedere e vedere i Suoi pool.
2. Limiti l'accesso. Non esponga Xen Orchestra a Internet. Vates consiglia di collocarlo su una rete di gestione dedicata, raggiungibile solo dagli amministratori, ad esempio tramite VPN.
3. Blocchi l'infrastruttura dell'aggressore. Vates consiglia regole di filtraggio in ingresso e in uscita per 91.211.251.112 e il blocco del traffico Tor, così che gli host non possano raggiungere ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. Se non può aggiornare immediatamente, blocchi il token vuoto in un WAF o in un reverse proxy posto davanti a Xen Orchestra. Filtri i pattern di cookie authenticationToken=j:{} e authenticationToken=j:%7B%7D.
5. Verifichi la presenza di una compromissione (vedi la sezione seguente). Se trova segni di compromissione, cambi tutte le password e i segreti utilizzati nei Suoi ambienti Xen Orchestra e XCP-ng, e analizzi gli host e le VM interessati.

Come verificare se è interessato

Innanzitutto, controlli la versione di Xen Orchestra nell'interfaccia web o sull'appliance. Se è precedente alla 6.9.1 (stable) o alla 6.10.0 (latest), il sistema è vulnerabile.

Vates e i report pubblicati elencano i seguenti indicatori di compromissione per la campagna di attacco nota:

• richieste HTTP contenenti authenticationToken=j:%7B%7D o authenticationToken=j:{}
• connessioni verso 91.211.251.112:8001 o ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• una macchina virtuale denominata pivot2
• macchine virtuali configurate con hvm_serial: file
• i file /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 e /.ustar6

Sugli host XCP-ng, esegua i controlli raccomandati da 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*

Cerchi inoltre una VM denominata pivot2, ad esempio con xe vm-list name-label=pivot2.

Secondo i report, Xen Orchestra non registra il cookie manipolato. Può rilevarlo solo tramite il monitoraggio HTTP, ad esempio nei log di accesso di un reverse proxy posto davanti a Xen Orchestra. Controlli tali log e i log del firewall per i pattern di cookie e gli indirizzi indicati sopra. Vates precisa che questi indicatori appartengono a una campagna nota. Altri aggressori possono lasciare tracce diverse, quindi non trovarne alcuna non dimostra che un sistema sia pulito.

Fonti

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