HD Doctor Logo

Falha crítica no Xen Orchestra já é explorada: o que fazer com as suas VMs e backups

Por Equipe Técnica HD Doctor

Resposta direta

Se a sua empresa administra XCP-ng pelo Xen Orchestra ou pelo appliance XOA, atualize hoje. Em 10/11/2026, a Vates publicou o advisory VSA-2026-062, de severidade crítica, e confirmou que a falha já é explorada: um cookie adulterado faz o painel aceitar o invasor como administrador, sem senha. O aviso indica como corrigidos o Xen Orchestra 6.9.2 (canal stable) e 6.10.1 (canal latest), com xo-server 5.211.2 e 5.213.1. O ataque não deixa registro nos logs do Xen Orchestra. Antes de mexer no ambiente, confirme que existe cópia das VMs fora do alcance do painel.

O que a Vates publicou em 10/11/2026

Em 10/11/2026, a Vates, empresa que mantém o XCP-ng e o Xen Orchestra, publicou o advisory VSA-2026-062, de severidade crítica. Até a nossa consulta, em 11/11/2026, o aviso não trazia número de CVE nem pontuação CVSS. Segundo o fabricante, o painel trata mal o cookie de autenticação da API REST: um valor adulterado vira um objeto vazio, a busca de tokens devolve o primeiro token existente e, se ele ainda for válido, o pedido é autenticado como o dono desse token. Depois disso, o invasor consegue listar tokens de login reutilizáveis. Fonte: https://docs.vates.tech/security-advisories/advisories/2026/vates-sa-2026-062/. A Vates afirma que a vulnerabilidade está sendo explorada ativamente por um agente de ameaça e que o invasor passa a agir com privilégio de administrador. Ainda segundo o aviso, comprometer o Xen Orchestra pode levar à execução de código nos pools gerenciados e à tomada completa de um host XCP-ng como root. A exploração bem-sucedida não gera entrada nos logs do Xen Orchestra; a detecção depende de monitorar o tráfego HTTP. São afetados o Xen Orchestra anterior à versão 6.9.2 (canal stable) e à 6.10.1 (canal latest) e o Xen Orchestra Appliance (XOA). Os pacotes corrigidos são o xo-server 5.211.2 (stable) e o 5.213.1 (latest). Para instalações feitas a partir do código-fonte, a orientação é atualizar para o master mais recente. Parte da imprensa citou as versões 6.9.1 e 6.10.0 como corrigidas; na nossa consulta, o advisory indicava 6.9.2 e 6.10.1. Confira o aviso antes de considerar o ambiente protegido. O advisory lista sinais desta campanha: uma VM chamada pivot2, VMs com o parâmetro hvm_serial: file e os arquivos /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 e /.ustar6 nos hosts, além de endereços IP usados pelos atacantes. A própria Vates avisa que outros grupos podem agir de forma diferente e que não encontrar esses sinais não prova que o ambiente está limpo. Se houver comprometimento, o fabricante recomenda trocar todas as senhas e segredos do ambiente, incluindo as credenciais dos destinos de backup, e reinstalar por completo, porque a limpeza pode não remover todas as portas dos fundos. Para quem guarda dados em VMs, a consequência é direta: quem administra o Xen Orchestra alcança as VMs, os discos virtuais e os repositórios de armazenamento dos pools que ele gerencia. É também no Xen Orchestra que ficam configurados os jobs de backup e os destinos onde as cópias são gravadas. O advisory não relata VMs apagadas nem cifradas; o que ele descreve é acesso de administrador e implantação de portas dos fundos. Mas o mesmo acesso permite desligar, copiar, alterar ou apagar VMs e snapshots, e backups geridos pelas mesmas credenciais ficam ao alcance. Se houver dano real em VMs, discos virtuais ou repositórios de armazenamento, a HD Doctor pode avaliar a recuperação conforme o material preservado. Essa avaliação não certifica a segurança do ambiente, não substitui a resposta a incidentes e não garante recuperar conteúdo perdido.

Quatro erros que podem custar as VMs

  1. 1.
    Deixar o Xen Orchestra acessível pela internet. A Vates orienta não expor o painel à internet e mantê-lo em uma rede de gerência dedicada. Remova redirecionamentos de porta e use VPN para acesso remoto. Isso reduz o risco, mas não substitui a atualização.
  2. 2.
    Concluir que está tudo bem porque o log não mostra nada. A exploração não deixa registro nos logs do Xen Orchestra. Verifique os sinais listados no advisory e lembre que a ausência deles não prova que o ambiente está limpo.
  3. 3.
    Manter os backups ao alcance do mesmo painel. Se todas as cópias estão em destinos configurados no Xen Orchestra e acessíveis com as credenciais guardadas nele, quem toma o painel alcança também os backups. Mantenha ao menos uma cópia offline ou imutável.
  4. 4.
    Reinstalar hosts sem antes preservar os dados. A reinstalação recomendada pela Vates em caso de comprometimento é o caminho certo para o sistema, mas formatar o repositório errado apaga discos virtuais. Antes, confirme cópias íntegras das VMs e identifique onde cada disco está.

Cinco passos para quem usa Xen Orchestra e XCP-ng

Os quatro primeiros valem para qualquer ambiente com Xen Orchestra ou XOA; o último, para quem encontrou sinais de invasão. Não tente reproduzir o ataque no ambiente de produção.

  1. 1

    Confira a versão e atualize

    Veja a versão do Xen Orchestra e do xo-server e compare com o VSA-2026-062: 6.9.2 com xo-server 5.211.2 no canal stable, ou 6.10.1 com xo-server 5.213.1 no canal latest. Instalações a partir do código-fonte devem ir para o master mais recente.

  2. 2

    Tire o painel da internet

    Coloque o Xen Orchestra em uma rede de gerência dedicada e remova qualquer publicação direta. Enquanto a atualização não for aplicada, bloqueie no firewall os endereços IP listados no advisory.

  3. 3

    Procure os sinais da campanha

    Verifique se existe uma VM chamada pivot2, VMs com hvm_serial: file e os arquivos /etc/cron.d/zz-ustar* e /.ustar* nos hosts XCP-ng. Os comandos de verificação estão no advisory. Resultado limpo não descarta invasão.

  4. 4

    Garanta e teste uma cópia fora do painel

    Confirme que as VMs críticas têm backup em destino que o Xen Orchestra não consegue apagar, offline ou imutável, e restaure uma VM de teste. Backup que nunca foi restaurado não está comprovado.

  5. 5

    Se houver sinais de invasão, preserve antes de reconstruir

    Isole o painel e os hosts da rede, anote horários e versões e troque senhas, tokens e credenciais dos destinos de backup, como orienta a Vates. Antes de reinstalar, preserve os discos e repositórios com VMs sem cópia íntegra e acione a resposta a incidentes.

Perguntas sobre o VSA-2026-062

A falha já está sendo explorada?

Sim. No advisory de 10/11/2026, a Vates afirma que a vulnerabilidade é explorada ativamente por um agente de ameaça e lista endereços e arquivos ligados à campanha. O aviso não informa quantos ambientes foram atingidos.

Meu Xen Orchestra só é acessível pela rede interna. Preciso atualizar?

Sim. Sem exposição à internet o risco cai, e essa é uma das medidas indicadas pela Vates, mas um computador infectado na rede interna pode alcançar o painel. O fabricante recomenda atualizar o quanto antes.

Atualizei. Posso considerar o ambiente seguro?

A atualização fecha a falha, mas não desfaz um acesso que já tenha ocorrido, e o ataque não deixa registro nos logs do Xen Orchestra. Procure os sinais do advisory. Em caso de comprometimento, a Vates recomenda trocar todos os segredos e reinstalar por completo.

Quando procurar recuperação profissional?

Quando VMs, discos virtuais ou repositórios de armazenamento forem apagados, cifrados ou ficarem inacessíveis e não houver backup validado. Preserve os discos, não reinstale nem formate sobre eles e informe versões, tipo de armazenamento, sintomas e o que já foi tentado. A viabilidade é avaliada no diagnóstico.

Perdeu VMs ou discos virtuais?

Preserve os discos e informe versões, tipo de armazenamento, sintomas e tentativas já feitas.

Próximas leituras