Xen Orchestra: falla già sfruttata, aggiorna subito

Cosa è successo

Il 10 novembre 2026 Vates ha pubblicato l'avviso VSA-2026-062, ripreso da BleepingComputer, su una falla critica in Xen Orchestra e nell'Xen Orchestra Appliance (XOA), i programmi usati per amministrare i server virtuali XCP-ng. Nell'avviso Vates scrive che la falla è già sfruttata da un attaccante.

Chi la sfrutta può entrare con i privilegi di amministratore. Da lì, secondo l'avviso di Vates, la compromissione può portare all'esecuzione di codice sui gruppi di server gestiti e al controllo completo, con i massimi privilegi (root), di un nodo XCP-ng.

Come funziona l'attacco

Per quanto riportato, Xen Orchestra gestisce male i cookie e i token di autenticazione inviati nelle richieste alla sua interfaccia REST. L'attaccante manda un cookie costruito apposta, che contiene un valore vuoto: il programma pesca un token di accesso già esistente e fa entrare l'attaccante al posto del suo proprietario, senza password.

Serve però poter raggiungere l'interfaccia di gestione dalla rete. Vates precisa anche che Xen Orchestra non ha un registro (log) che segnali l'accesso non autenticato: per accorgersene si può guardare il traffico HTTP.

Cosa non si sa ancora

Una sola fonte primaria. L'avviso Vates è l'unica fonte di prima mano sullo sfruttamento. La correzione nel codice è confermata anche su GitHub, ma lì non si parla di attacchi.

I numeri. L'avviso non riporta né un codice CVE né un punteggio CVSS (la gravità è indicata solo come «critica»). Non nomina chi attacca né quante installazioni siano esposte.

Quali versioni sono vulnerabili. Secondo l'avviso Vates, quelle precedenti alla 6.9.2 (ramo stabile) e alla 6.10.1 (ultima). Il pacchetto xo-server è corretto nelle versioni 5.211.2 e 5.213.1.

Cosa fare

Segui le indicazioni dell'avviso Vates:

1. Aggiorna Xen Orchestra alla 6.9.2 (stabile) o alla 6.10.1 (ultima); per xo-server servono la 5.211.2 o la 5.213.1. Se hai installato Xen Orchestra dai sorgenti, Vates raccomanda caldamente di aggiornare all'ultimo master.
2. Se non puoi aggiornare subito, limita l'accesso a Xen Orchestra a reti di gestione dedicate e blocca gli otto indirizzi IP indicati da Vates: 91.211.251.112, 193.148.56.72, 37.221.208.216, 45.66.35.11, 64.65.0.120, 64.65.62.160, 89.47.51.90 e 92.60.37.247. Vates suggerisce anche di bloccare il traffico Tor (per impedire il collegamento con l'indirizzo .onion dell'attaccante). La regola per il firewall applicativo (WAF) suggerita da Vates si può aggirare: non basta da sola.
3. Se sospetti di essere stato colpito, cambia le password e i segreti usati dall'ambiente di virtualizzazione. Se la compromissione è confermata, Vates raccomanda la reinstallazione completa: una semplice pulizia non può garantire la rimozione di tutte le backdoor (accessi nascosti) lasciate dall'attaccante.
4. Cerca i segnali indicati da Vates. Nel traffico HTTP (con strumenti come tcpdump o Wireshark): richieste con il cookie authenticationToken=j:%7B%7D (o j:{}). Vates indica inoltre che l'attaccante ha operato inizialmente da 91.211.251.112:8001 e da un indirizzo .onion (rete Tor) sulla porta 3333: sono la provenienza dell'attacco, non un segno da cercare nel traffico. Sui server: una macchina virtuale chiamata pivot2, o con l'impostazione hvm_serial: file, e i file /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 e /.ustar6. Vates precisa che valgono per questa campagna e potrebbero non servire per altri attaccanti.

Da dove vengono questi dati

La fonte principale è l'avviso VSA-2026-062 di Vates del 10 novembre 2026, letto per intero; la correzione è nella richiesta di modifica n. 10748 su GitHub, unita al codice principale il 10 novembre. BleepingComputer ha riportato la notizia lo stesso giorno. La scoperta è attribuita ai ricercatori Filip Magic e Christoffer Olsen di TDC NET Security.