361 Servidores vCenter Atingidos Antes da Lista KEV

Nove Dias da Correção a 361 Vítimas

A Broadcom publicou o aviso VMSA-2026-0006 a 29 de julho de 2026, revelando a CVE-2026-59310 juntamente com uma falha complementar de contorno de autenticação, a CVE-2026-59309, no VMware vCenter Server 8.0, 9.0 e 9.1. As versões corrigidas ficaram disponíveis no mesmo dia: vCenter 9.1.0.0300, vCenter 9.0.2.0100 e vCenter 8.0 U3k ou U2f, consoante o ramo de atualização utilizado.

A QUIRSO GmbH, uma empresa alemã de informática forense e resposta a incidentes, refere que a infraestrutura controlada pelo atacante registou as primeiras ligações de entrada a partir de sistemas vCenter explorados a 3 de agosto de 2026, apenas cinco dias após o lançamento da correção. Até 7 de agosto, a empresa tinha contabilizado 361 endereços IP de vítimas distintos, distribuídos por 47 países, com cerca de metade concentrada na Alemanha, nos Estados Unidos, na Turquia, no Irão e em França. A QUIRSO publicou uma regra de deteção YARA juntamente com as suas conclusões, mas reteve alguns indicadores de compromisso enquanto coordenava com as autoridades.

Uma Função Syslog Que Entrega Todo o Servidor

A CVE-2026-59310 reside na lógica de tratamento de diretórios do componente Syslog Server do vCenter. O próprio aviso da Broadcom afirma sem rodeios que um agente malicioso com acesso de rede ao vCenter pode explorar o problema para executar código arbitrário, e, de forma decisiva, sem necessitar de autenticação prévia. Esta combinação, ausência de autenticação mais execução de código ao nível do sistema, é o que valeu a esta falha a sua pontuação de gravidade de 9.8 em 10 e o que torna qualquer instância de vCenter acessível a partir da internet num alvo imediato, e não apenas teórico.

O vCenter não é uma ferramenta periférica. É o plano de gestão de todo o parque de virtualização de uma organização, a consola que aprovisiona, migra e controla cada máquina virtual que uma empresa utiliza. Um aviso do fabricante para este produto em concreto nunca deveria esperar na mesma fila que uma correção de aplicação de rotina.

Porque o reverse_ssh Contorna a Regra de Firewall Que Já Tem

Em vez de abrir uma porta a escutar no servidor vCenter comprometido, algo que a maioria da monitorização de rede está preparada para sinalizar, os atacantes por detrás desta campanha instalam o reverse_ssh, uma ferramenta de código aberto em Go que faz com que a máquina comprometida estabeleça uma ligação SSH de saída de volta para a infraestrutura do atacante. Como a ligação é de saída, consegue escapar às políticas de firewall e de rede configuradas para bloquear tráfego de entrada não solicitado mas que deixam passar sessões de saída com aspeto normal, dando ao atacante um ponto de apoio duradouro e interativo capaz de sobreviver a uma simples revisão de segmentação de rede.

Para um dispositivo que já ocupa uma posição central no parque de virtualização de uma organização, este mecanismo de persistência transforma um único servidor vCenter não corrigido numa cabeça de ponte duradoura, em vez de uma intrusão pontual.

Tese Original: O Fosso da KEV É Aqui a Verdadeira História

A maioria da cobertura sobre vulnerabilidades mede a urgência consoante uma falha tenha ou não entrado no catálogo Known Exploited Vulnerabilities da CISA, e muitos programas de correções estão construídos, formal ou informalmente, precisamente à volta desse mesmo gatilho. A CVE-2026-59310 quebra esse pressuposto. A telemetria independente tanto da QUIRSO como da empresa de segurança Rapid7 documentou centenas de comprometimentos reais em 47 países na primeira semana e meia após a divulgação, e ainda assim, no momento em que este artigo foi escrito, a CVE continuava sem aparecer no catálogo da CISA. Um fluxo de correções que trata a inclusão na KEV como o sinal para escalar um aviso do vCenter a estado de emergência estava, por definição, já semanas atrasado em relação aos atacantes que encontraram e armaram esta falha.

A lição vai além desta única CVE. Para software ao nível da infraestrutura como uma consola de gestão de hipervisor, a telemetria de uma empresa forense independente, ou a própria pontuação de gravidade do fabricante, deveria bastar por si só para desencadear correções de emergência, sem esperar por uma entrada num catálogo governamental que, desta vez, simplesmente não chegou a tempo.

O Que os Operadores do vCenter Devem Fazer Agora

Qualquer organização que utilize vCenter 8.0, 9.0 ou 9.1 e que ainda não tenha aplicado as correções de 29 de julho deve tratar isto como uma alteração de emergência, e não como uma alteração planeada, devendo também confirmar que a interface de gestão não está diretamente acessível a partir da internet pública, o que nunca deveria acontecer em primeiro lugar. Tendo em conta o método de persistência de saída aqui documentado, monitorizar as ligações SSH de saída iniciadas por servidores ao nível da infraestrutura, e não apenas o acesso de entrada a estes, passa agora a fazer parte de uma estratégia de deteção completa para esta campanha em concreto.

Para as entidades essenciais e importantes da UE ao abrigo do NIS2 que tinham instâncias de vCenter acessíveis a partir da internet ou de outra forma expostas durante a janela de exploração, este incidente enquadra-se exatamente nas categorias para as quais a diretiva foi escrita: execução remota de código não autenticada em infraestrutura com exploração ativa confirmada e uma possibilidade real de impacto na confidencialidade, integridade ou disponibilidade de todo o parque de virtualização.

Leia a seguir: Uma Cadeia de Duas Chamadas Deu Root a 295 Atacantes  |  CVSS 9.6: falha atingiu balanceadores 792 vezes