Bypass de autenticação no Xen Orchestra dá acesso de administrador e pode levar à tomada de hosts XCP-ng

O que aconteceu

Em 10 de novembro de 2026, a Vates publicou o alerta de segurança VSA-2026-062 sobre um bypass de autenticação crítico no Xen Orchestra. O Xen Orchestra é a interface de gerenciamento via web para ambientes de virtualização XCP-ng. Ainda não foi atribuído um ID CVE nem uma pontuação CVSS.

A falha está na forma como a REST API trata o cookie de login. Um cookie com o valor authenticationToken=j:%7B%7D é interpretado como um objeto vazio ({}). Esse objeto é passado para a verificação do token sem que se confirme que se trata de uma string. A busca do token então retorna o primeiro token armazenado, e a requisição é autenticada como o dono desse token, desde que o token não tenha expirado. Pelo endpoint /rest/v0/users/me/authentication_tokens, um atacante pode então ler IDs de tokens de login reutilizáveis.

Segundo a Vates, um atacante pode usar isso para executar ações com privilégios de Admin no Xen Orchestra sem credenciais. Isso pode levar à execução arbitrária de código nos pools gerenciados e à tomada completa dos hosts XCP-ng como root.

A Vates afirma que a vulnerabilidade está sendo explorada ativamente por um agente de ameaça que opera a partir de 91.211.251.112:8001 e de um endereço Tor (veja abaixo). Não se sabe quando os ataques começaram nem se a falha foi explorada antes da liberação da correção. A falha foi descoberta por Filip Magic e Christoffer Olsen da TDC NET Security.

Quem é afetado

• Xen Orchestra anterior à 6.9.1 (canal stable) e anterior à 6.10.0 (canal latest)
• os pacotes xo-server correspondentes anteriores à 5.211.2 (stable) e à 5.213.1 (latest)
• o Xen Orchestra Appliance (XOA)

O atacante precisa de acesso de rede à interface web do Xen Orchestra. Instâncias acessíveis pela internet têm o maior risco. Os hosts XCP-ng também estão em risco, porque o Xen Orchestra os gerencia. Se você não usa o Xen Orchestra, este alerta não afeta você.

O que fazer agora

1. Atualize o Xen Orchestra. Instale o Xen Orchestra 6.9.1 no canal stable ou o 6.10.0 no canal latest. Essas versões incluem o xo-server 5.211.2 (stable) ou 5.213.1 (latest). Faça um backup da configuração do Xen Orchestra antes. Após a atualização, confirme que o xo-server está em execução e que você consegue fazer login e ver seus pools.
2. Restrinja o acesso. Não exponha o Xen Orchestra na internet. A Vates recomenda colocá-lo em uma rede de gerenciamento dedicada, acessível apenas por administradores, por exemplo por meio de uma VPN.
3. Bloqueie a infraestrutura do atacante. A Vates recomenda regras de filtragem de entrada e saída para 91.211.251.112 e o bloqueio do tráfego Tor, para que os hosts não consigam alcançar ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion.
4. Se não puder atualizar imediatamente, bloqueie o token vazio em um WAF ou reverse proxy na frente do Xen Orchestra. Procure os padrões de cookie authenticationToken=j:{} e authenticationToken=j:%7B%7D.
5. Verifique se houve comprometimento (veja a próxima seção). Se encontrar sinais de comprometimento, troque todas as senhas e segredos usados nos seus ambientes Xen Orchestra e XCP-ng e investigue os hosts e VMs afetados.

Como verificar se você é afetado

Primeiro, verifique a versão do Xen Orchestra na interface web ou no appliance. Se ela for anterior à 6.9.1 (stable) ou à 6.10.0 (latest), o sistema está vulnerável.

A Vates e os relatórios publicados listam estes indicadores de comprometimento para a campanha de ataque conhecida:

• requisições HTTP contendo authenticationToken=j:%7B%7D ou authenticationToken=j:{}
• conexões com 91.211.251.112:8001 ou ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion:3333
• uma máquina virtual chamada pivot2
• máquinas virtuais configuradas com hvm_serial: file
• os arquivos /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 e /.ustar6

Nos hosts XCP-ng, execute as verificações recomendadas pela 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*

Também procure uma VM chamada pivot2, por exemplo com xe vm-list name-label=pivot2.

Segundo os relatórios, o Xen Orchestra não registra o cookie elaborado. Você só consegue detectá-lo por meio de monitoramento HTTP, por exemplo nos logs de acesso de um reverse proxy na frente do Xen Orchestra. Verifique esses logs e os logs do seu firewall em busca dos padrões de cookie e dos endereços acima. A Vates observa que esses indicadores pertencem a uma campanha conhecida. Outros atacantes podem deixar rastros diferentes, portanto não encontrar nenhum deles não comprova que um sistema está limpo.

Fontes

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