A Broadcom publicou uma atualização de segurança crítica para duas vulnerabilidades no VMware Workstation e VMware Fusion capazes de romper uma das barreiras mais importantes da virtualização.
Em determinadas condições, um invasor que já possua privilégios administrativos dentro de uma máquina virtual pode explorar as falhas e conseguir executar código no sistema operacional hospedeiro.
Na prática, o ataque pode transformar uma máquina virtual que deveria estar isolada em uma ponte para atingir o computador físico que a executa.
As vulnerabilidades são identificadas como:
CVE-2026-59346 — CVSS 9,3 — Crítica
CVE-2026-59347 — CVSS 8,1 — Importante
A Broadcom publicou o boletim VMSA-2026-0007 em 3 de setembro de 2026 e disponibilizou atualizações para os produtos afetados.
Não existe workaround oficial.
A recomendação é atualizar para a versão 26H1u1.
Por que essas vulnerabilidades são tão importantes?
O princípio fundamental de uma máquina virtual é o isolamento.
Imagine um computador executando Windows, Linux ou macOS.
Dentro dele, um software de virtualização cria outro computador virtual.
Esse segundo ambiente pode executar:
outro sistema operacional;
programas;
arquivos;
serviços;
código potencialmente perigoso;
ou até malware em ambientes de análise.
A expectativa é que aquilo que acontece dentro da máquina virtual permaneça dentro dela.
As novas vulnerabilidades desafiam justamente essa premissa.
O ataque é conhecido como VM escape
Quando código executado dentro de uma máquina virtual consegue atravessar a camada de virtualização e atingir o sistema hospedeiro, temos uma classe de ataque conhecida como:
VM escape — escape de máquina virtual.
É um dos cenários mais preocupantes em virtualização.
Uma máquina virtual pode ser criada justamente porque seu operador não confia no código que será executado dentro dela.
Pesquisadores de segurança, por exemplo, frequentemente analisam malware dentro de VMs para reduzir o risco ao computador principal.
Se existe uma vulnerabilidade de escape, essa separação pode ser quebrada.
CVE-2026-59346 é a vulnerabilidade mais grave
A primeira falha está localizada no VMXNET3, adaptador de rede virtual utilizado por máquinas virtuais VMware.
A vulnerabilidade é resultado de um integer overflow, ou estouro de inteiro.
A Broadcom atribuiu:
CVSS 9,3.
Classificação:
Crítica.
Segundo o fabricante, um agente malicioso com privilégios administrativos locais dentro de uma VM que utilize o adaptador virtual VMXNET3 pode explorar a vulnerabilidade para:
executar código no host.
Essa última parte é justamente o que torna o problema tão grave.
O ataque começa dentro da VM.
Mas termina fora dela.
O que é VMXNET3?
Uma máquina virtual precisa conversar com a rede.
Para isso, o software de virtualização apresenta ao sistema convidado uma placa de rede virtual.
VMXNET3 é um adaptador de rede paravirtualizado desenvolvido para ambientes VMware.
Ele é utilizado para oferecer desempenho elevado e eficiência de comunicação entre a máquina virtual e a infraestrutura de virtualização.
Mas essa comunicação exige interação entre componentes existentes dentro e fora da VM.
É justamente nessa fronteira que vulnerabilidades podem se tornar particularmente perigosas.
Um integer overflow pode alterar completamente o comportamento do software
Computadores armazenam números em espaços de tamanho limitado.
Quando uma operação matemática ultrapassa aquilo que aquele espaço consegue representar, pode ocorrer um integer overflow.
Dependendo da forma como o software utiliza o resultado, isso pode provocar:
cálculos incorretos;
alocação inadequada de memória;
corrupção;
leitura ou escrita fora dos limites esperados;
e, em casos mais graves, execução de código.
É essa classe de problema que aparece na CVE-2026-59346.
A segunda vulnerabilidade está no HGFS
A CVE-2026-59347 possui uma origem diferente.
Ela recebeu:
CVSS 8,1.
A falha é um stack-based buffer overflow, ou estouro de buffer baseado na pilha, localizado no HGFS.
HGFS significa Host Guest File System.
O componente está associado à comunicação e ao compartilhamento de arquivos entre o sistema hospedeiro e a máquina virtual.
Novamente, estamos falando exatamente de uma interface que atravessa a fronteira entre os dois ambientes.
Compartilhamento entre host e VM aumenta a superfície de ataque
Recursos de compartilhamento são extremamente convenientes.
Um usuário pode transferir arquivos entre seu computador principal e a máquina virtual sem precisar configurar servidores ou mecanismos externos.
Mas toda funcionalidade que permite comunicação entre dois ambientes também cria uma superfície adicional.
O HGFS precisa receber informações provenientes da VM e processá-las no contexto da infraestrutura de virtualização.
Se esse processamento possui uma vulnerabilidade de memória, um invasor pode tentar manipulá-lo.
CVE-2026-59347 permite atingir o processo VMX
Segundo a Broadcom, um agente malicioso com privilégios administrativos locais dentro da máquina virtual pode explorar a CVE-2026-59347 para executar código como o processo VMX da própria VM rodando no host.
O VMX é um componente central da execução de uma máquina virtual VMware.
Portanto, conseguir executar código nesse contexto representa uma quebra importante da separação esperada entre guest e host.
As duas vulnerabilidades exigem acesso administrativo à VM
Existe uma limitação essencial que precisa aparecer em qualquer análise do caso.
As falhas não permitem que qualquer pessoa na internet simplesmente assuma um computador executando VMware Workstation ou Fusion.
Segundo a Broadcom, o invasor precisa possuir:
privilégios administrativos locais dentro da máquina virtual.
Isso muda significativamente o modelo de ameaça.
Não estamos diante de uma vulnerabilidade pré-autenticação diretamente explorável pela internet.
Mas isso não torna o problema pequeno
Em muitos ambientes, conseguir privilégios administrativos dentro da VM já significaria um comprometimento grave.
Mas existem cenários em que esse nível de privilégio é completamente normal.
Por exemplo:
laboratórios de malware;
ambientes de desenvolvimento;
CTFs;
máquinas de testes;
VMs utilizadas para executar software desconhecido;
ambientes de pesquisa;
imagens fornecidas por terceiros;
laboratórios educacionais;
e determinadas estações compartilhadas.
Nesses casos, o usuário ou software dentro da VM pode ter privilégios elevados por design.
O isolamento oferecido pelo hypervisor é justamente aquilo que deveria impedir que o risco chegasse ao host.
Imagine um pesquisador analisando malware
Um profissional de cibersegurança recebe uma amostra suspeita.
Para não executá-la diretamente em seu computador, cria uma máquina virtual.
Dentro dela, executa o malware com privilégios administrativos para observar:
arquivos criados;
processos;
alterações no registro;
conexões;
persistência;
e comportamento.
A VM existe justamente como barreira.
Agora imagine que o malware saiba explorar uma vulnerabilidade de VM escape.
Ele poderia tentar sair do ambiente de análise e atingir o computador do pesquisador.
Esse é o tipo de cenário que torna falhas dessa classe especialmente relevantes.
Desenvolvedores também precisam prestar atenção
VMware Workstation é amplamente utilizado por desenvolvedores e profissionais de infraestrutura.
É comum executar dentro de VMs:
aplicações de teste;
imagens de clientes;
ambientes legados;
servidores;
software de terceiros;
ferramentas experimentais;
e diferentes distribuições Linux.
Se uma dessas imagens não for confiável, o risco não deve ser avaliado apenas pelo que existe dentro dela.
Uma vulnerabilidade de escape altera o modelo de segurança.
Quais versões são vulneráveis?
O boletim da Broadcom identifica como afetadas as versões:
VMware Workstation 25H2 e 26H1
e
VMware Fusion 25H2 e 26H1.
Para o Fusion, o ambiente hospedeiro é o macOS.
No Workstation, o software é utilizado em sistemas desktop compatíveis como Windows e Linux.
As duas vulnerabilidades foram corrigidas em:
26H1u1.
Portanto, usuários dessas versões devem verificar se já estão executando o release corrigido.
Não existe workaround oficial
Esse é outro ponto particularmente importante do boletim.
Para ambas as CVEs, a Broadcom informa:
Workarounds: None.
Ou seja, o fabricante não publicou uma mitigação alternativa oficialmente suportada que elimine o risco sem instalar a correção.
A solução indicada é:
aplicar a atualização.
Não confundir mitigação operacional com correção
É possível reduzir determinadas superfícies de ataque modificando a configuração do ambiente.
Por exemplo, deixar de utilizar recursos que dependam de determinado componente vulnerável pode reduzir oportunidades de exploração.
Mas isso não equivale ao patch.
E, principalmente, não deve ser apresentado como workaround oficial da Broadcom.
O fabricante foi explícito:
não existe workaround.
Para remover a vulnerabilidade conhecida, é necessário atualizar.
Não há confirmação pública de exploração ativa
Outro ponto importante da apuração:
até o momento, não existe confirmação pública de que CVE-2026-59346 ou CVE-2026-59347 estejam sendo exploradas em ataques reais.
Isso diferencia o caso de vulnerabilidades já incluídas em catálogos de exploração conhecida ou associadas a campanhas observadas no mundo real.
Também não há atribuição pública de um grupo criminoso explorando essas duas falhas.
Portanto, seria incorreto afirmar que hackers já estão utilizando as vulnerabilidades contra usuários do VMware.
Falhas foram reportadas de maneira privada
As vulnerabilidades chegaram à Broadcom por meio de pesquisadores de segurança.
No caso da CVE-2026-59346, a empresa agradeceu pesquisadores ligados ao secsys lab e à TrendAI Zero Day Initiative por reportarem independentemente o problema.
A CVE-2026-59347 foi reportada independentemente por pesquisadores do Tencent Xuanwu Lab.
Esse processo permitiu que correções fossem preparadas antes da divulgação pública dos detalhes básicos.
A classificação das duas falhas é diferente
Existe um detalhe interessante no boletim.
A CVE-2026-59346 é individualmente classificada como:
Critical — 9,3.
Já a CVE-2026-59347 aparece como:
Important — 8,1.
Entretanto, o boletim VMSA-2026-0007 como um todo recebeu severidade:
CRITICAL.
Por isso, dizer simplesmente que “a Broadcom corrigiu duas falhas críticas” pode perder um pouco da precisão.
A formulação mais correta é:
um boletim crítico contendo uma vulnerabilidade crítica e outra de severidade importante.
As duas, porém, possuem capacidade de atravessar a fronteira guest-host em suas respectivas condições.
Isso não é uma falha do VMware ESXi
Essa distinção também é essencial para ambientes corporativos.
As duas vulnerabilidades do boletim de setembro atingem:
VMware Workstation
e
VMware Fusion.
O advisory VMSA-2026-0007 não lista VMware ESXi nem vCenter como produtos afetados por essas duas CVEs.
Isso é importante porque o VMware ESXi é utilizado em grandes infraestruturas de servidores e data centers, enquanto Workstation e Fusion são produtos de virtualização desktop.
Broadcom corrigiu outras falhas graves no ESXi recentemente
A confusão é compreensível porque a Broadcom publicou outro grande boletim VMware pouco mais de um mês antes.
O VMSA-2026-0006, de 29 de julho, tratou de vulnerabilidades diferentes envolvendo:
VMware ESX;
vCenter;
Workstation;
Fusion;
VMware Cloud Foundation;
vSphere Foundation;
e plataformas de telecomunicações.
Entre elas estava a CVE-2026-47876, relacionada ao VMXNET3 e demonstrada durante o Pwn2Own Berlin 2026.
Mas ela é uma CVE diferente.
Não deve ser confundida com a nova:
CVE-2026-59346.
Pwn2Own Berlin expôs outra vulnerabilidade no VMXNET3
Durante o Pwn2Own Berlin, em maio, um pesquisador conseguiu demonstrar uma exploração contra VMware ESX.
A Broadcom posteriormente corrigiu o problema no boletim de julho.
O fato de uma nova vulnerabilidade aparecer agora novamente envolvendo VMXNET3 chama atenção para a complexidade desses componentes.
Mas isso não significa que estamos diante da mesma falha ou de uma correção incompleta.
São vulnerabilidades diferentes.
Virtualização depende de uma fronteira extremamente complexa
A segurança de uma máquina virtual depende de uma ideia aparentemente simples:
guest de um lado;
host do outro.
Na prática, existem várias interfaces entre eles.
Rede.
Vídeo.
Áudio.
USB.
Clipboard.
Arquivos.
Memória.
Dispositivos virtuais.
Drivers.
Integrações.
Cada uma dessas interfaces precisa permitir funcionalidades sem permitir que código do guest atravesse a fronteira de maneira indevida.
É uma tarefa de engenharia extremamente complexa.
Dispositivos virtuais são uma superfície crítica
Quando um sistema operacional dentro da VM acredita estar conversando com uma placa de rede, por exemplo, ele na verdade está interagindo com uma implementação virtualizada.
O hypervisor precisa interpretar os comandos enviados pelo guest.
Uma entrada inesperada ou especialmente construída pode atingir falhas no código responsável por essa emulação.
É por isso que vulnerabilidades em:
adaptadores de rede;
controladores;
GPU virtual;
USB;
e sistemas de arquivos compartilhados
são tão relevantes para a segurança de hypervisors.
Uma VM não deve ser considerada uma barreira absoluta
Virtualização continua sendo uma excelente tecnologia de isolamento.
Mas não é uma garantia matemática de que código malicioso nunca conseguirá sair do guest.
Historicamente, diferentes hypervisors já receberam correções para vulnerabilidades de escape.
Por isso, ambientes que utilizam VMs como mecanismo de segurança precisam tratar o próprio hypervisor como software crítico.
Ele também precisa ser:
atualizado;
monitorado;
endurecido;
e protegido.
Snapshots não corrigem o problema
Outro erro comum é acreditar que snapshots resolvem riscos desse tipo.
Snapshots são excelentes para retornar uma VM a um estado anterior.
Mas eles não corrigem uma vulnerabilidade no software de virtualização instalado no host.
Se o hypervisor permanece vulnerável, restaurar a VM não elimina a possibilidade de uma nova exploração.
O patch precisa estar no componente correto.
Antivírus dentro da VM também não é suficiente
Um endpoint security instalado dentro do guest pode detectar determinadas atividades maliciosas.
Mas o problema aqui envolve justamente a fronteira entre o guest e o host.
Uma estratégia de segurança adequada precisa proteger ambos.
A máquina virtual não substitui segurança no host.
E segurança no host não substitui atualização do hypervisor.
Empresas devem descobrir onde Workstation está instalado
Existe um desafio prático importante.
VMware Workstation nem sempre é tratado como infraestrutura central.
Pode estar instalado individualmente nos computadores de:
desenvolvedores;
analistas;
administradores;
pesquisadores;
engenheiros;
consultores;
equipes de suporte;
e profissionais de segurança.
Isso dificulta o inventário.
Uma organização pode atualizar todos os servidores VMware e ainda possuir dezenas de notebooks executando versões vulneráveis do Workstation.
Fusion merece atenção nos Macs corporativos
O mesmo vale para o VMware Fusion.
Em empresas que utilizam macOS, desenvolvedores podem executar máquinas virtuais para testar:
Linux;
Windows;
software corporativo;
ambientes de desenvolvimento;
e aplicações legadas.
Esses Macs podem possuir acesso privilegiado a:
repositórios;
cloud;
VPN;
credenciais;
código-fonte;
e sistemas internos.
Portanto, comprometer o host de um desenvolvedor pode ter consequências muito maiores do que comprometer apenas uma VM descartável.
CI/CD e ambientes de build também merecem revisão
Outro cenário importante envolve automação.
Algumas organizações utilizam virtualização desktop ou ambientes derivados para:
builds;
testes;
pipelines;
laboratórios;
e validação de imagens.
Quando código fornecido por terceiros ou proveniente de diferentes projetos é executado com privilégios elevados dentro de uma VM, a possibilidade de escape precisa ser considerada.
Especialmente quando o host possui segredos utilizados pelo pipeline.
A correção precisa entrar no inventário de vulnerabilidades
Para equipes de segurança, a prioridade deveria ser identificar:
quais máquinas possuem VMware Workstation ou Fusion;
qual versão está instalada;
quais VMs utilizam VMXNET3;
onde existem compartilhamentos host-guest;
quais ambientes executam código não confiável;
e quais hosts possuem acesso a informações críticas.
A partir daí, a atualização para 26H1u1 deve ser priorizada.
Quem analisa malware deve receber prioridade máxima
Mesmo sem exploração ativa conhecida, laboratórios de malware possuem um modelo de ameaça especial.
Eles executam intencionalmente código hostil.
Se algum malware incorporar exploração dessas vulnerabilidades no futuro, esse tipo de ambiente poderá se tornar um alvo natural.
Portanto, esta é uma correção que merece atenção especial de:
SOC;
CSIRT;
CERT;
pesquisadores;
equipes de threat intelligence;
reverse engineers;
e laboratórios de análise.
Não é motivo para abandonar máquinas virtuais
O surgimento de uma vulnerabilidade de escape não significa que VMs deixaram de ser seguras ou úteis.
Virtualização continua sendo fundamental para infraestrutura moderna.
A lição é diferente:
isolamento também depende de software — e software possui vulnerabilidades.
Quanto mais crítica for a fronteira de segurança, mais importante é manter o componente responsável por ela atualizado.
O título original está essencialmente correto
A informação publicada de que a Broadcom corrigiu duas vulnerabilidades capazes de quebrar o isolamento entre máquinas virtuais e o host está correta.
Mas três detalhes precisam acompanhar a notícia para evitar uma interpretação exagerada:
o atacante precisa possuir privilégios administrativos dentro da VM;
as CVEs divulgadas neste boletim atingem Workstation e Fusion, não o ESXi;
e
não existe, até agora, confirmação pública de exploração ativa dessas duas vulnerabilidades.
Isso não diminui a importância das correções.
A CVE-2026-59346 recebeu CVSS 9,3, o boletim é classificado como crítico e a Broadcom não oferece workaround.
Em ambientes nos quais máquinas virtuais executam software potencialmente hostil, a conclusão é simples:
se a VM existe para proteger o host, uma falha capaz de atravessar essa fronteira deve ser tratada como prioridade.
