Existe uma diferença prática entre comprometer um servidor e comprometer o que controla todos os servidores. O VMware vCenter é a segunda categoria: é o painel único que administra a frota inteira de hipervisores ESXi, guarda credenciais de domínio e fala com cada máquina virtual do ambiente. Em 29 de julho de 2026 a Broadcom publicou o advisory VMSA-2026-0006 com duas falhas críticas nele. Cinco dias depois já existia exploração ativa em escala global.
As duas falhas críticas do VMSA-2026-0006
A CVE-2026-59310 é uma vulnerabilidade de directory traversal no servidor de syslog do vCenter, com CVSS 3.1 de 9,8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) e classificada como CWE-22. Um atacante com acesso de rede ao vCenter, sem nenhuma credencial e sem interação de usuário, consegue executar código arbitrário. A companheira dela é a CVE-2026-59309, também 9,8 e com o mesmo vetor, um bypass de autenticação no VMware Directory Service (vmdir) classificado como CWE-303, implementação incorreta de algoritmo de autenticação. As duas foram publicadas na NVD em 30 de julho de 2026.
- VMware vCenter 9.1.x anterior a 9.1.0.0300, 9.0.x anterior a 9.0.2.0100 e 8.0 anterior a U3k
- VMware Cloud Foundation 9.1.x, 9.0.x e 5.x
- VMware vSphere Foundation 9.1.x e 9.0.x
- VMware Telco Cloud Infrastructure 3.0
- VMware Telco Cloud Platform 5.1.x, 5.0.x, 4.x e 3.0
A correção está no VMware Cloud Foundation e vSphere Foundation 9.1.0.0300, no 9.0.2.0100 e no vCenter Server 8.0 U3k. Não há workaround oficial que substitua o patch, o que significa que a única resposta real é atualizar.
Como a falha é explorada
O componente vulnerável é o serviço de syslog do vCenter Server Appliance. Servidor de log é um alvo clássico e um pouco irônico: a função dele é receber dado não confiável de fontes externas e gravar esse dado em disco. Quando o caminho do arquivo de destino é montado a partir de conteúdo controlado pelo atacante sem normalização, a sequência de traversal escapa do diretório de logs e o serviço passa a escrever onde o atacante quiser. E um processo que escreve em qualquer caminho do sistema, rodando com privilégio alto, é execução de código em um passo indireto.
# Conceito da falha (CWE-22), nao um exploit funcional.
# O destino do log e montado a partir de entrada externa:
/var/log/vmware/syslog/<valor_controlado_pelo_atacante>.log
# Sem normalizacao do caminho, a sequencia de traversal escapa do diretorio:
../../../../etc/cron.d/update
# Resultado: o conteudo da mensagem de syslog vira o corpo de um arquivo
# em /etc/cron.d, e o cron do appliance executa esse conteudo sozinho.
# A escrita arbitraria de arquivo vira execucao de comando sem exploit de memoria.Vale reparar no que essa cadeia não exige. Não tem corrupção de memória, não tem bypass de ASLR, não tem shellcode. É validação de entrada ausente em um caminho de arquivo, a mesma classe de falha que existe desde os anos 1990, num produto de infraestrutura crítica em 2026. É por isso que revisão de caminho de arquivo continua sendo item obrigatório de checklist em pentest de aplicação.
O que acontece depois do primeiro comando
A telemetria publicada pela QUIRSO, empresa alemã de resposta a incidente que rastreou a campanha, mostra uma operação bem mais organizada que um scan oportunista. Depois do acesso inicial, o atacante busca o backdoor com curl ou wget, instala um implante que abre canal de comando e controle por WebSocket, e garante persistência por múltiplos caminhos redundantes ao mesmo tempo.
- Persistência redundante: entradas de cron, serviços systemd e injeção de chave SSH, além do reverse_ssh, ferramenta open source usada para manter sessão reversa com a infraestrutura do atacante
- Escalonamento: configuração de sudo sem senha e criação de contas administrativas próprias no appliance
- Roubo de credencial: extração direta do vmdir, o diretório que guarda a identidade de todo o ambiente vSphere
- Movimento lateral: descoberta dos hosts ESXi pela API REST e uso da própria API do vSphere para operar sobre eles
- Impacto final: implantação de ransomware derivado do Babuk nos hosts ESXi, cifrando arquivos com a extensão .babyk
Um detalhe da análise da QUIRSO merece atenção de quem faz resposta a incidente: os pesquisadores suspeitam que o ransomware pode ter sido distração, não o objetivo real. Criptografia é barulhenta por natureza, ela força a vítima a olhar para o incidente. Quando aparece no fim de uma cadeia que já tinha roubo de credencial de diretório e acesso à API de virtualização, vale considerar a hipótese de que a extorsão serviu para encobrir o que já saiu do ambiente.
Cinco dias entre o patch e a exploração em massa
A QUIRSO detectou os primeiros sistemas comprometidos falando com infraestrutura de comando e controle em 3 de agosto de 2026, cinco dias corridos depois da divulgação. Atividade ligada à CVE-2026-59309 já aparecia desde 1º de agosto. No total foram 361 endereços IP únicos comprometidos em 47 países, com maior concentração na Alemanha (55), Estados Unidos (41), Turquia (38), Irã (26) e França (25). Até a publicação deste post as duas falhas ainda não constavam no catálogo Known Exploited Vulnerabilities da CISA, o que é um bom lembrete de que ausência no KEV não é evidência de ausência de exploração.
A QUIRSO atribui a campanha, com confiança moderada, a um ator com nexo chinês, com base em artefatos em chinês nos scripts do atacante, reuso de pesquisa e ferramentas de origem chinesa, vitimologia que exclui a China continental e padrão de atividade compatível com o fuso UTC+08:00. Atribuição é sempre probabilística e não muda a resposta técnica, mas ajuda a calibrar expectativa: ator estatal com esse nível de organização não some do ambiente porque o ransomware foi contido.
Triagem: como saber se você já foi comprometido
Se o seu vCenter ficou exposto e sem patch em qualquer momento entre 29 de julho e hoje, aplicar a atualização resolve a vulnerabilidade mas não desfaz um comprometimento anterior. A persistência dessa campanha sobrevive ao patch, porque ela não depende mais da falha. A triagem mínima é procurar pelos mecanismos de persistência descritos, e ela deve vir antes de considerar o caso encerrado.
# Triagem no vCenter Server Appliance (leitura, nao altera nada).
# 1. Versao instalada, para confirmar se esta corrigido
vpxd -v
# 2. Tarefas agendadas suspeitas (o vetor de persistencia mais direto)
ls -la /etc/cron.d/ /etc/cron.daily/
crontab -l
# 3. Servicos systemd criados ou modificados recentemente
ls -lat /etc/systemd/system/ | head -20
# 4. Chaves SSH injetadas em qualquer conta
find / -name authorized_keys -type f -exec ls -la {} \; 2>/dev/null
# 5. Regras de sudo sem senha adicionadas
grep -rn NOPASSWD /etc/sudoers /etc/sudoers.d/ 2>/dev/null
# 6. Contas locais criadas depois da data do advisory
ls -la /home/- Aplique o patch primeiro, mas trate patch e triagem como duas tarefas separadas
- Tire o vCenter da exposição direta à internet, ele nunca deveria estar alcançável fora da rede de administração
- Rotacione as credenciais do vmdir e as contas de serviço do vSphere se houver qualquer indício de comprometimento
- Revise as contas administrativas do appliance e dos hosts ESXi procurando por criação recente
- Verifique se os backups dos hosts ESXi estão fora do alcance de quem administra o vCenter
Por que a camada de virtualização merece escopo próprio
Na maioria dos escopos de pentest que recebemos, a camada de virtualização entra como infraestrutura de apoio, quando entra. O foco vai para a aplicação exposta, para a API, para o perímetro. Mas o vCenter concentra três coisas ao mesmo tempo: identidade (via vmdir), controle de execução (via API do vSphere) e acesso ao disco de toda máquina virtual do ambiente. Comprometer um servidor de aplicação dá ao atacante um servidor. Comprometer o vCenter dá o data center.
O padrão que se repete nos últimos casos críticos é sempre o mesmo: o alvo de maior valor não é o sistema mais visível, é o sistema que administra os outros. Vale conferir hoje se o seu escopo de teste inclui o painel que controla tudo, ou se ele foi classificado como rede interna e nunca chegou a ser testado.