A vulnerabilidade CVE-2026-47876 no adaptador de rede virtual VMXNET3 do VMware ESXi permite que um atacante com privilégios administrativos locais em uma máquina virtual execute código diretamente no host hipervisor — um cenário de escape de VM que compromete todas as cargas de trabalho hospedadas no servidor afetado. A falha integra o advisory crítico VMSA-2026-0006, publicado pela Broadcom, que corrige cinco vulnerabilidades em produtos VMware.
Risco de escape de VM
O VMXNET3 é o adaptador de rede virtual de alto desempenho usado por padrão em máquinas virtuais VMware. A vulnerabilidade de gravação fora dos limites (out-of-bounds write) nesse componente representa uma das classes de ataque mais temidas em virtualização: o escape de VM. Assim como em vetores de ransomware, o ponto de partida é um ambiente já parcialmente comprometido — neste caso, uma VM onde o atacante obteve privilégios de administrador.
Um atacante que já comprometa uma máquina virtual com privilégios administrativos pode usar a falha para saltar a fronteira de isolamento do hipervisor e executar código no próprio host ESXi, comprometendo todas as máquinas virtuais hospedadas naquele servidor físico. Uma vez no host, o invasor ganha controle sobre discos virtuais inteiros e pode clonar, exfiltrar ou destruir dados de tenants vizinhos que deveriam permanecer isolados.
Esse modelo de ameaça é especialmente relevante para provedores de nuvem, ambientes VDI (Virtual Desktop Infrastructure) e data centers corporativos que consolidam múltiplas cargas no mesmo host. A economia de escala da virtualização depende da premissa de isolamento entre máquinas virtuais — premissa que o CVE-2026-47876 quebra para qualquer host não corrigido.
Como a falha funciona
A Broadcom classificou o CVE-2026-47876 com nota CVSS 9,3 (Crítica) e confirmou que não existe nenhuma solução alternativa (workaround) — a única remediação é aplicar o patch do fabricante. A falha afeta exclusivamente máquinas virtuais configuradas com o adaptador VMXNET3; adaptadores virtuais não-VMXNET3, como E1000 e E1000E, não são impactados.
O ataque não é explorável remotamente por um invasor externo sem acesso prévio. Ele exige privilégios administrativos locais dentro da máquina virtual alvo. Em arquiteturas de nuvem compartilhada, basta um único inquilino comprometido para tentar escalar até o host e, a partir dele, atingir máquinas virtuais vizinhas. A vulnerabilidade foi descoberta por Nguyen Hoang Thach (@hi_im_d4rkn3ss), da STARLabs SG, durante o Pwn2Own organizado pela Zero Day Initiative — evidência de que a falha é prática e explorável em condições reais de competição de segurança.
Versões afetadas e correções
O mesmo advisory VMSA-2026-0006 também corrige o CVE-2026-59309, uma vulnerabilidade de bypass de autenticação no VMware Directory Service do vCenter com CVSS 9,8, que permite a um atacante remoto sem autenticação acessar o plano de gerenciamento. Juntas, as falhas cobrem tanto o vetor de guest-to-host (VMXNET3) quanto o vetor de rede contra o vCenter.
A tabela abaixo resume as versões afetadas e as respectivas correções para o CVE-2026-47876:
| Produto | Versão afetada | Versão corrigida |
|---|---|---|
| Cloud Foundation / vSphere Foundation | ESX 9.1.x.x | ESXi-9.1.0.0200-25557999 |
| Cloud Foundation / vSphere Foundation | ESX 9.0.x.x | ESXi-9.0.2.0100-25595025 |
| VMware ESX | 8.0 | ESXi80U3k-25595708 |
| VMware Cloud Foundation | 5.x | Async patch (KB88287) |
| VMware Telco Cloud Platform | 5.0.x, 5.1.x | KB449886 |
A Broadcom publicou o VMSA-2026-0006 em 29 de julho de 2026 e classificou a severidade geral do advisory como Crítica, com notas CVSS variando de 2,7 a 9,8 entre as cinco vulnerabilidades incluídas. Por não haver workaround para nenhuma das falhas críticas, a atualização é o único caminho de remediação.
Plano de mitigação imediato
Ações recomendadas para equipes que administram ambientes VMware ESXi:
- Inventarie hosts e versões: identifique todos os hosts ESXi das versões 9.1.x, 9.0.x e 8.0 e liste quais máquinas virtuais usam o adaptador VMXNET3.
- Priorize hosts multi-tenant: aplique o patch primeiro em hosts que abrigam VMs de diferentes tenants, aplicações ou níveis de criticidade, pois o escape de VM tem maior impacto ali.
- Considere troca de adaptador: em VMs de alto risco onde o patch ainda não foi aplicado, avalie a troca temporária do adaptador VMXNET3 por E1000E — ressaltando que isso pode reduzir o desempenho de rede.
- Restrinja privilégios de VM: limite quem tem privilégios administrativos dentro de máquinas virtuais e monitore contas com acesso de administrador local, já que esse é o pré-requisito do ataque.
- Monitore logs do host: após a correção, verifique indicadores de comprometimento no ESXi, incluindo criação não autorizada de snapshots, clonagem de VMs e alterações de configuração do host.
- Confirme cumulatividade dos patches: os patches são cumulativos, então valide que a versão instalada inclui todas as correções anteriores e não apenas a mais recente.