Xen Orchestra: una falla di autenticazione sfruttata dà diritti di amministratore sulla virtualizzazione XCP-ng

Monitoraggio cyber di Top-Secured: analisi indipendente basata sulle fonti citate più in basso. Top-Secured non è affiliato alle aziende menzionate e non le chiederà mai le sue credenziali bancarie né le sue password.

Vates ha corretto una falla critica in Xen Orchestra, la console web che gestisce gli host XCP-ng, e segnala che è già sfruttata. Basta un cookie manipolato per farsi passare, senza password, per un utente esistente, di solito un amministratore. Le versioni 6.9.2 e 6.10.1 la correggono; le console esposte vanno anche controllate.

Cosa è successo

Il 10 novembre 2026 la società francese Vates, che sviluppa Xen Orchestra e XCP-ng, ha pubblicato l’avviso VSA-2026-062, di gravità critica, precisando che la falla è sfruttata attivamente. Al momento della pubblicazione non aveva un identificativo CVE né un punteggio CVSS. Le versioni corrette sono uscite lo stesso giorno.

Il difetto si trova nell’autenticazione dell’API REST. Un cookie il cui token è un oggetto vuoto costruito ad arte, invece di una stringa di testo, arriva senza controlli alla ricerca dei token. Questa restituisce allora il primo token valido salvato da Xen Orchestra, e la richiesta viene trattata come se provenisse dal suo proprietario. Da lì l’attaccante può elencare token di accesso riutilizzabili e agire con diritti di amministratore. La correzione, integrata su GitHub, rifiuta qualsiasi token che non sia una stringa non vuota.

Chi è a rischio

Tutte le installazioni di Xen Orchestra precedenti a 6.9.2 (canale stable) e 6.10.1 (canale latest), sia l’appliance XOA sia le versioni compilate dai sorgenti. Secondo Vates, il controllo della console può portare all’esecuzione di codice sui pool gestiti e all’accesso root agli host XCP-ng. Le console raggiungibili da Internet sono in prima linea.

Cosa fare subito

1. Aggiornate: XOA a 6.9.2 (stable) o 6.10.1 (latest), cioè xo-server 5.211.2 o 5.213.1; le installazioni dai sorgenti all’ultimo commit di master, poi ricompilate.
2. Togliete la console da Internet: solo una rete di amministrazione dedicata o una VPN.
3. Filtrate: bloccate gli indirizzi IP e l’indirizzo Tor elencati nell’avviso e, sul reverse proxy, le richieste il cui cookie authenticationToken inizia con j:. Vates avverte che altre codifiche possono aggirare una regola del genere.
4. Cercate tracce: un attacco riuscito non lascia nulla nel registro di autenticazione. Cercate una VM chiamata pivot2, poi su ogni host XCP-ng eseguite xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', zgrep -- '-serial file:' /var/log/xensource.log* e ls -la /etc/ld.so.preload /.ustar* /etc/cron.d/zz-ustar*.
5. In caso di compromissione: cambiate tutti i segreti noti alla piattaforma (account root, segreto del pool, destinazioni di backup, proxy, utenti, segreti OTP, server di posta) e, come raccomanda Vates, reinstallate invece di ripulire.

La nostra analisi

La console di un hypervisor custodisce le chiavi di tutte le macchine virtuali: è il server più sensibile dell’azienda e non deve stare su Internet. Questa volta la patch non basta: poiché l’attacco non lascia tracce di accesso, solo un controllo degli host dirà se qualcuno è già entrato.

Fonti

• 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

Come scegliamo, verifichiamo e scriviamo le nostre analisi →