Xen Orchestra: falha de autenticação explorada dá direitos de administrador sobre a virtualização XCP-ng

Monitoramento cibernético da Top-Secured: análise independente baseada nas fontes citadas abaixo. A Top-Secured não é afiliada às empresas mencionadas e nunca pedirá seus dados bancários nem suas senhas.

A Vates corrigiu uma falha crítica no Xen Orchestra, o console web que gerencia os hosts XCP-ng, e informa que ela já está sendo explorada. Um cookie manipulado basta para se passar, sem senha, por um usuário existente, em geral um administrador. As versões 6.9.2 e 6.10.1 corrigem o problema; os consoles expostos também precisam ser verificados.

O que aconteceu

Em 10 de novembro de 2026, a empresa francesa Vates, responsável pelo Xen Orchestra e pelo XCP-ng, publicou o alerta VSA-2026-062, classificado como crítico, e afirma que a falha está sendo explorada ativamente. Na publicação, não havia identificador CVE nem pontuação CVSS. As versões corrigidas saíram no mesmo dia.

O defeito está na autenticação da API REST. Um cookie cujo token é um objeto vazio forjado, em vez de uma cadeia de texto, chega sem verificação à busca de tokens. Essa busca devolve então o primeiro token válido salvo pelo Xen Orchestra, e a requisição é tratada como se viesse do dono desse token. A partir daí, o atacante pode listar tokens de login reutilizáveis e agir com direitos de administrador. A correção, integrada no GitHub, rejeita qualquer token que não seja uma cadeia não vazia.

Quem está em risco

Todas as instalações do Xen Orchestra anteriores a 6.9.2 (canal stable) e 6.10.1 (canal latest), seja o appliance XOA ou uma compilação a partir do código-fonte. Segundo a Vates, assumir o controle do console pode levar à execução de código nos pools gerenciados e a acesso root aos hosts XCP-ng. Os consoles acessíveis pela internet são os primeiros da fila.

O que fazer agora

1. Atualize: XOA para 6.9.2 (stable) ou 6.10.1 (latest), ou seja, xo-server 5.211.2 ou 5.213.1; instalações a partir do código-fonte para o último commit de master, depois recompile.
2. Tire o console da internet: somente rede de administração dedicada ou VPN.
3. Filtre: bloqueie os endereços IP e o endereço Tor listados no alerta e, no proxy reverso, as requisições cujo cookie authenticationToken comece com j:. A Vates avisa que outras codificações podem contornar esse tipo de regra.
4. Procure rastros: um ataque bem-sucedido não deixa nada no log de autenticação. Procure uma VM chamada pivot2 e, em cada host XCP-ng, execute 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. Em caso de comprometimento: troque todos os segredos conhecidos pela plataforma (contas root, segredo do pool, destinos de backup, proxies, usuários, segredos OTP, servidor de e-mail) e, como recomenda a Vates, reinstale em vez de limpar.

Nossa análise

O console de um hipervisor guarda as chaves de todas as máquinas virtuais: é o servidor mais sensível da empresa e não deve ficar na internet. Aplicar a correção não basta desta vez: como o ataque não deixa rastro de login, só uma verificação dos hosts dirá se alguém já entrou.

Fontes

• 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

Como escolhemos, verificamos e escrevemos nossas análises →