Nota 9.8 no VMware vCenter: a falha crítica que entrega todos seus servidores de uma só vez

Nota 9.8 de 10. Na escala que mede a gravidade de vulnerabilidades, esse número descreve o pior cenário possível: dá para explorar de fora, pela rede, sem senha nenhuma e sem que a vítima precise clicar em nada.

Foi essa a nota que a falha recém-corrigida do VMware vCenter recebeu. E no caso dele a consequência não se limita a um servidor: o vCenter é o painel que comanda todos os servidores virtuais da empresa.

A Broadcom publicou a correção em 29 de julho. Cinco dias depois, em 3 de agosto, os ataques começaram — e hoje já são 361 servidores comprometidos em 47 países.

Por que o vCenter é um alvo tão valioso

Vale explicar sem jargão, porque isso é o que dimensiona o risco.

A maioria das empresas não tem um servidor físico por sistema. Tem alguns servidores potentes rodando máquinas virtuais — dezenas de “servidores” que existem como software dentro deles. O vCenter é o painel que controla toda essa estrutura: cria, liga, desliga, move e faz cópia dessas máquinas.

Ou seja: quem domina o vCenter não invade um servidor, invade todos de uma vez. Pode desligar sistemas, copiar máquinas inteiras (com os dados dentro), criar servidores próprios na sua infraestrutura ou criptografar tudo. É a chave do cofre inteiro, não de uma gaveta.

A falha, em linguagem simples

A vulnerabilidade recebeu o código CVE-2026-59310 e nota 9.8 de 10 — praticamente o teto da escala.

Tecnicamente é um problema de travessia de diretório no componente de registro de logs (Syslog) do vCenter. Na prática: o sistema aceitava que um pedido de fora indicasse um caminho de arquivo fora da área permitida. Explorando isso, o atacante consegue executar código remotamente — rodar comandos no servidor sem precisar de senha.

O que os invasores fizeram depois de entrar

Aqui está a parte que diferencia um ataque oportunista de uma operação organizada. Após obter acesso, o grupo:

• Instalou um shell reverso — um canal que faz o servidor invadido “ligar de volta” para o atacante, o que atravessa firewall com mais facilidade do que uma conexão de fora para dentro.
• Criou tarefas agendadas (cron) e backdoors para manter o acesso mesmo depois de reinicializações.
• Configurou SSH reverso como via de retorno.
• Roubou credenciais guardadas no ambiente — o passo que permite continuar circulando pela rede mesmo depois de a falha original ser corrigida.
• Implantou ransomware derivado do Babuk, uma família conhecida de programa de extorsão.

Uma empresa alemã de resposta a incidentes analisou a campanha e avaliou, com confiança moderada, que o grupo é de língua chinesa e opera no fuso UTC+08:00 — a atribuição vem de padrões de horário de atividade e de infraestrutura, não de uma confissão. Vale registrar como probabilidade, não como fato consumado.

Entre as vítimas, metade se concentra em Alemanha, Estados Unidos, Turquia, Irã e França. Não é um ataque direcionado a um setor: é varredura ampla procurando quem ainda não atualizou.

As três lições que importam para a sua empresa

1. A correção existir não protege ninguém. Este é o terceiro caso que cobrimos no mês com o mesmo roteiro — Exchange, macOS e agora vCenter. O fabricante corrige, a notícia sai, o exploit aparece e o ataque em massa começa em dias. A vulnerabilidade não vive no software: vive no intervalo entre o boletim e o seu agendamento de manutenção.

2. Infraestrutura crítica exige um caminho de urgência. Servidor de virtualização não se atualiza numa terça à tarde qualquer — exige janela, teste e coordenação. Justamente por isso precisa existir um procedimento de exceção: o que fazemos quando sai um 9.8 no nosso hipervisor? Se a resposta for “entra na fila do próximo trimestre”, a fila é o risco.

3. Aplicar o patch não encerra o incidente. Este ponto é o mais esquecido. Se o servidor foi comprometido antes da atualização, o backdoor, o cron malicioso e as credenciais roubadas continuam lá depois dela. Corrigir fecha a porta — não expulsa quem já entrou.

O que fazer, na ordem

• Atualize o vCenter. As versões corrigidas são 9.1.0.0300, 9.0.2.0100, 8.0 U3k e 8.0 U2f. Se sua empresa terceiriza a infraestrutura, essa é a pergunta para o fornecedor hoje: “em que versão está nosso vCenter?”
• Nunca exponha o vCenter à internet. Painel de administração de virtualização se acessa por rede interna ou VPN. Se ele responde a partir de fora, você está no alvo da próxima varredura, seja qual for a falha.
• Se estava desatualizado durante a janela de ataque (3 a 13 de agosto), presuma comprometimento e investigue: tarefas cron que ninguém criou, conexões de saída incomuns, chaves SSH desconhecidas, contas administrativas novas.
• Troque as credenciais do ambiente de virtualização se houver qualquer suspeita. Senha roubada continua valendo depois do patch.
• Confirme que o backup está isolado. Ransomware em ambiente virtualizado tenta apagar as cópias primeiro. Backup acessível a partir do ambiente que ele domina não é backup.

Se dá para tirar um resumo de tudo isso: a segurança de infraestrutura crítica é, na prática, uma disciplina de prazo. Não foi conhecimento técnico que separou as 361 vítimas de quem passou ilesa — foram cinco dias.

Fontes

• Broadcom — advisory oficial de segurança do VMware vCenter (CVE-2026-59310): support.broadcom.com
• NVD / NIST — registro oficial da CVE-2026-59310: nvd.nist.gov
• CISA — catálogo de vulnerabilidades exploradas conhecidas (KEV): cisa.gov
• Broadcom / VMware — matriz de versões e notas de lançamento do vCenter: techdocs.broadcom.com