A vulnerabilidade CVE-2026-47876, divulgada no aviso VMSA-2026-0006 da Broadcom em 29 de julho de 2026, é uma falha crítica de escrita fora dos limites no adaptador de rede virtual VMXNET3 do VMware ESX, avaliada em CVSS 9,3. O explor bem-sucedido permite que um atacante com privilégios administrativos locais em uma máquina virtual escape do isolamento do guest e execute código diretamente no host ESXi subjacente. A Broadcom não oferece workaround, tornando a atualização do hypervisor a única remediação disponível para fechar a falha.

O VMSA-2026-0006 abrange cinco vulnerabilidades nos produtos VMware e inclui também duas falhas de CVSS 9,8 no vCenter Server — um bypass de autenticação no VMware Directory Service (CVE-2026-59309) e uma path traversal no servidor Syslog (CVE-2026-59310). Embora as falhas do vCenter dominem a cobertura da imprensa, o CVE-2026-47876 é a única vulnerabilidade do conjunto que permite escape de máquina virtual (guest-to-host), uma classe de risco especialmente grave em ambientes multi-tenant de nuvem.

Mecanismo da fuga de VM

O VMXNET3 é o adaptador de rede virtual de alto desempenho adotado por padrão em máquinas virtuais VMware. A falha CVE-2026-47876 reside no processamento de operações de rede desse adaptador dentro do componente VMX do ESXi. Um atacante que já tenha comprometido uma VM e obtido privilégios administrativos locais pode enviar sequências de requisições malformadas que provocam uma escrita fora dos limites de memória no processo do host responsável pela virtualização da placa de rede.

Como consequência, o atacante consegue executar código arbitrário no contexto do hypervisor, quebrando o isolamento que deveria manter cada VM confinada. Esse tipo de falha é conhecido como VM escape e representa a quebra mais severa do modelo de segurança de virtualização: o comprometimento não se limita à VM atacante, mas pode se estender a todas as demais máquinas virtuais e dados hospedados no mesmo host físico.

A Broadcom confirmou em seu advisory que apenas máquinas virtuais equipadas com o adaptador VMXNET3 estão vulneráveis e que adaptadores virtuais diferentes não são afetados. A descoberta foi creditada a Nguyen Hoang Thach, da STARLabs SG, que demonstrou a exploração durante o Pwn2Own organizado pela Zero Day Initiative — um dos eventos de pesquisa de segurança mais reconhecidos da indústria.

Versões afetadas e corrigidas

A tabela resume as builds corrigidas por linha de produto conforme o VMSA-2026-0006:

Produto Versão afetada Build corrigida
Cloud Foundation / vSphere Foundation 9.1.x.x ESXi-9.1.0.0200-25557999
Cloud Foundation / vSphere Foundation 9.0.x.x ESXi-9.0.2.0100-25595025
VMware ESX 8.0 ESXi80U3k-25595708
Cloud Foundation 5.x Async patch (KB88287)
Telco Cloud Platform 5.0.x / 5.1.x KB449886

Por que não há workaround

A Broadcom declarou expressamente no advisory que não existe nenhuma medida de mitigação temporária para o CVE-2026-47876. Diferente de vulnerabilidades em que a desativação de um serviço ou o bloqueio de uma porta reduz o risco, esta falha opera dentro do caminho de dados de rede do hypervisor, funcionalmente essencial ao funcionamento das VMs.

Em ambientes onde a atualização imediata não for viável, a estratégia de redução de risco é limitar quem detém privilégios administrativos dentro de cada VM, reforçar o monitoramento de atividades anômalas nos guests e isolar em hosts dedicados as VMs de menor confiança ou expostas a multi-tenancy, especialmente em contextos de infraestrutura crítica. Essas medidas reduzem a probabilidade de exploração, mas não eliminam a vulnerabilidade — apenas o patch oficial restaura o isolamento garantido pelo hypervisor.

Passos para corrigir o ESXi

Equipes de infraestrutura devem priorizar a aplicação das builds corrigidas seguindo o roteiro abaixo:

  1. Inventarie hosts afetados: liste todos os servidores ESXi e identifique quais executam as versões 8.0, 9.0.x.x ou 9.1.x.x com VMs que usam adaptador VMXNET3.
  2. Baixe a build corrigida: obtenha o patch correspondente no portal de suporte da Broadcom conforme a versão instalada em cada host.
  3. Planeje a janela de manutenção: coloque cada host em modo de manutenção e migre as VMs para outros hosts via vMotion para evitar interrupção.
  4. Aplique o patch: instale a build corrigida — por exemplo, ESXi80U3k-25595708 para ESXi 8.0 — usando o vSphere Lifecycle Manager ou o comando esxcli.
  5. Reinicie e valide: faça o reboot do host, confirme a nova versão no vCenter e monitore os logs por comportamento anômalo, de forma semelhante à investigação de uma falha crítica de execução remota de código.
  6. Repita em todos os hosts: siga o mesmo procedimento até que nenhum host vulnerável permaneça no ambiente.

Fontes