Cinco dias após o patch, o seu vCenter já podia estar nas mãos de intrusos

Uma falha crítica no VMware vCenter corrigida no final de julho está a ser explorada em ataques reais, apenas dias depois de a Broadcom ter divulgado a correção. A equipa de investigação de ameaças da empresa alemã QUIRSO afirma estar a acompanhar uma campanha de exploração ativa contra sistemas VMware vCenter acessíveis pela Internet e avalia que um suposto agente APT está a explorar a CVE-2026-59310 e a recorrer a SSH reverso para manter acesso aos sistemas comprometidos. Os investigadores identificaram 361 endereços IP de vítimas em 47 países, num caso que volta a colocar o plano de gestão da virtualização no centro das preocupações de qualquer organização que corra vSphere.

O que é a CVE-2026-59310 e porque é tão grave

Segundo a descrição da Broadcom, o VMware vCenter contém uma vulnerabilidade de directory traversal no servidor Syslog. O fabricante indica que um agente malicioso com acesso de rede ao vCenter pode explorar o problema para executar código arbitrário. A falha recebeu a pontuação CVSS máxima de 9,8, o patamar reservado a problemas exploráveis remotamente, com baixa complexidade e sem necessidade de credenciais.

A gravidade não vem apenas da pontuação. O vCenter Server é a consola central de gestão dos ambientes vSphere, permitindo administrar hosts ESXi, máquinas virtuais, alocação de recursos e disponibilidade a partir de um único plano de controlo — pelo que o seu comprometimento pode dar a um atacante um controlo significativo sobre todo o ambiente virtualizado e as respetivas cargas de trabalho. Em termos práticos, quem controla o vCenter controla praticamente tudo o que corre por baixo dele.

A falha não veio sozinha. A 29 de julho de 2026, a Broadcom publicou o aviso crítico VMSA-2026-0006, que corrige vulnerabilidades em VMware ESX, vCenter, Workstation e Fusion. São cinco falhas — CVE-2026-59309 (contorno de autenticação no vCenter), CVE-2026-59310 (directory traversal no vCenter), CVE-2026-47876 (escrita fora de limites no VMXNET3 do ESX), CVE-2026-41703 (leitura fora de limites em ESX, Workstation e Fusion) e CVE-2026-41709 (registo insuficiente no ESX) — com o aviso classificado globalmente como crítico e pontuações entre 2,7 e 9,8 em CVSS 3.1. As duas mais graves, CVE-2026-59309 e CVE-2026-59310, têm 9,8 e podem ser exploradas por um atacante não autenticado com acesso de rede ao vCenter.

Cronologia: da correção à exploração em cinco dias

Os dados sustentam esta sequência. O histórico do próprio aviso registra a publicação inicial a 29 de julho de 2026 e, a 3 de agosto, a versão VMSA-2026-0006.1 com os express patches ESX 8.0 U2f e vCenter 8.0 U2f. A QUIRSO observou sistemas afetados a estabelecer ligação a infraestrutura controlada pelos atacantes a 3 de agosto, cinco dias após o aviso; a atividade acelerou depois, com 151 endereços IP de vítimas adicionais a 4 de agosto e 343 dos 361 endereços observados — cerca de 95% — já registados a 5 de agosto.

À data do aviso, o cenário era outro: a Broadcom afirmou não ter informação que sugerisse exploração destas falhas em ambiente real e a Rapid7 registava, no momento da publicação da sua análise, ausência de evidência conhecida de exploração ou varrimentos, bem como de código de exploração público. A mesma equipa notava, ainda assim, que o vCenter Server já figurou dez vezes no catálogo KEV da CISA por outras vulnerabilidades, pelo que é sabido que os atacantes visam problemas críticos neste produto.

Como funciona o ataque e o que procurar

A avaliação da QUIRSO baseia-se em provas recolhidas durante um trabalho recente de resposta a incidente. Após a exploração, os investigadores observaram a instalação do reverse_ssh, uma ferramenta aberta de shell reverso baseada em SSH que suporta ligação de retorno, reencaminhamento de portas, transferência de ficheiros, vários transportes e gestão remota de shell — funcionalidade que, nas mãos de um intruso, cria um canal de controlo de saída com menor probabilidade de ser bloqueado por defesas focadas em ligações de entrada não solicitadas.

Há um aviso importante para as equipas de deteção: a presença do reverse_ssh não deve, por si só, ser tratada como prova de atividade maliciosa, mas, combinada com instalação não autorizada, ligações de saída inesperadas ou execução num appliance vCenter vulnerável, é um indicador de prioridade elevada que exige investigação. Para apoiar a caça a ameaças, a equipa desenvolveu uma regra YARA genérica para identificar builds do reverse_ssh, disponibilizada no GitHub, sublinhando que, tratando-se de uma ferramenta legítima de duplo uso, uma correspondência deve ser tratada como pista de investigação e correlacionada com outros sinais de comprometimento. Indicadores específicos do atacante e conteúdos de deteção adicionais serão publicados numa fase posterior.

• Ligações de saída anómalas a partir do appliance vCenter para domínios ou endereços desconhecidos.
• Tarefas agendadas ou entradas cron não autorizadas no appliance, usadas para manter persistência.
• Binários compatíveis com reverse_ssh em diretórios não habituais.
• Sinais de manipulação de caminhos de ficheiro nos registos associados ao componente Syslog do vCenter.
• Contas ou sessões administrativas criadas fora das janelas de manutenção conhecidas.

Sobre a atribuição, prudência: as conclusões apontam para um suposto agente de ameaça avançado e persistente a usar a falha para obter execução de código e estabelecer acesso remoto, mas não há identificação pública do grupo. Também os números devem ser lidos com cuidado: os valores descrevem infraestrutura e não uma contagem verificada de organizações, já que uma única organização pode usar vários endereços, enquanto redes de cloud, alojamento e partilhadas podem representar muitos inquilinos não relacionados.

Versões afetadas e correções

Estas são as versões corrigidas indicadas na análise da QUIRSO para as três linhas do vCenter, alinhadas com o que consta no aviso. O aviso foi entretanto atualizado para VMSA-2026-0006.1 com a adição de patches para o VMware vSphere 8.0 Update 2. Os ambientes VMware Cloud Foundation 5.x são corrigidos através do processo de patching assíncrono da Broadcom, enquanto as implementações VMware Telco Cloud Platform e Telco Cloud Infrastructure são cobertas por orientações específicas de produto. A Broadcom sublinha que o VMSA é sempre a fonte de verdade sobre produtos e versões afetados e sobre os patches corretos.

Mitigação: o que fazer esta semana

A Broadcom afirma que não existe solução de contorno para a CVE-2026-59310; os administradores devem identificar a versão corrigida aplicável na matriz de resposta do aviso e aplicar a atualização do fabricante sem demora. Como os patches são cumulativos, uma única atualização aplica todas as correções disponíveis para esse ramo de produto, não sendo necessário aplicar correções separadas por CVE. A Broadcom esclarece ainda pontos que geraram dúvidas: os problemas estão no próprio vCenter e não no Enhanced Linked Mode, estando presentes independentemente de esse modo ser usado — a resposta é atualizar o vCenter; e a Autenticação Integrada do Windows não está envolvida, nem nenhuma das cinco falhas se relaciona com integração de Active Directory, pois os problemas do vCenter existem independentemente da configuração das fontes de identidade.

• Inventariar todas as instâncias vCenter e ESX, incluindo ambientes de teste e laboratório esquecidos.
• Tratar a atualização como alteração de emergência e não como manutenção agendada.
• Retirar interfaces de gestão da exposição direta à Internet e restringir o acesso a uma rede de administração dedicada.
• Em sistemas potencialmente expostos antes do patch, assumir a possibilidade de comprometimento e conduzir uma avaliação forense.
• Rever cópias de segurança e credenciais administrativas usadas no plano de gestão.

Recomenda-se também atualizar o appliance vCenter antes dos hosts ESX que gere e remover imediatamente vCenter, ESX e todas as interfaces de gestão associadas da exposição direta à Internet, antes ou em paralelo com a aplicação dos patches. Vale a pena registar quem reportou as falhas: a Broadcom agradece a Phil Brass e Matt South, da Atredis Partners, por comunicarem o problema — ou seja, a divulgação foi coordenada, e a exploração surgiu depois de existir correção.

Porque é que isto importa em Portugal

Em Portugal, o vSphere é a base de muitos centros de dados privados, de fornecedores de serviços geridos e de organismos públicos. Uma falha que permite controlar o plano de gestão da virtualização coloca em causa, de uma só vez, disponibilidade, integridade e confidencialidade de praticamente todos os serviços alojados — desde sistemas de faturação de uma PME até bases de dados com informação pessoal de clientes ou utentes.

Do ponto de vista legal, este é o tipo de incidente que aciona obrigações. As entidades abrangidas pelo Regime Jurídico da Ciberseguranca, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a NIS2, têm de adotar medidas de gestão de risco proporcionais — o que inclui gestão de vulnerabilidades, segmentação da rede de administração e capacidade de deteção — e notificar incidentes significativos ao CNCS/CERT.PT nos prazos previstos. Se houver acesso a dados pessoais, acresce o dever de notificação à CNPD nos termos do RGPD, com prazo de 72 horas a contar do conhecimento da violação.

Para as PME sem equipa de segurança dedicada, a lição operacional é simples: o intervalo entre a publicação de uma correção crítica e a exploração massiva pode ser de dias, não de meses. Consolas de gestão nunca devem estar acessíveis a partir da Internet, o inventário de sistemas tem de estar atualizado e as janelas de manutenção precisam de um procedimento de exceção para patches de emergência. Para quem depende de fornecedores externos de alojamento ou de serviços geridos, a pergunta a fazer esta semana é direta: o vCenter que suporta os nossos sistemas já foi atualizado e estava exposto?

Perguntas frequentes

A minha organização está afetada?

Se utiliza VMware vCenter ou ESX em versões anteriores às indicadas como corrigidas no aviso VMSA-2026-0006.1, deve considerar-se afetada. A Broadcom recomenda consultar o próprio aviso como lista definitiva de produtos e versões e agir de imediato em caso de dúvida.

Existe alguma alternativa à atualização?

Não. A Broadcom afirma que não há soluções de contorno para as duas falhas críticas do vCenter, pelo que aplicar as versões corrigidas é a única remediação suportada. Restringir o acesso de rede ao plano de gestão reduz a superfície de ataque, mas não substitui o patch.

Como saber se o meu vCenter foi comprometido?

Procure instalações não autorizadas da ferramenta reverse_ssh, tarefas agendadas suspeitas e ligações de saída inesperadas a partir do appliance. Como se trata de uma ferramenta de duplo uso, qualquer deteção deve ser validada e correlacionada com outros sinais antes de se concluir que houve comprometimento.

Tenho de notificar as autoridades se houver incidente?

As entidades abrangidas pelo Regime Jurídico da Cibersegurança devem notificar incidentes significativos ao CNCS/CERT.PT nos prazos legais. Se houver acesso indevido a dados pessoais, aplica-se ainda o dever de notificação à CNPD no prazo de 72 horas previsto no RGPD.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Broadcom (VMSA-2026-0006.1), pela QUIRSO GmbH e por equipas de investigação de segurança que analisaram a campanha.