CVE-2025-22225
Priorize a correção. Ela está sob exploração confirmada pelo CISA.
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
Resumo
CVE-2025-22225 é uma vulnerabilidade de escrita arbitrária (CWE-123) no VMware ESXi que permite a um atacante que já tenha privilégios dentro do processo VMX escrever em memória do kernel do hypervisor, escapando do sandbox do VMX. Não é uma falha de acesso inicial: ela é o segundo elo de uma cadeia de escape de VM revelada junto com CVE-2025-22224 e CVE-2025-22226 no VMSA-2025-0004, reportada pela Microsoft Threat Intelligence Center. Está no catálogo KEV da CISA com exploração confirmada in the wild pela Broadcom, o que eleva sua prioridade mesmo com CVSS 8.2 (abaixo do 9.3 da falha "de entrada" da mesma cadeia).
Detalhamento técnico
A falha reside no ESXi e é classificada como CWE-123 (write-what-where condition): o atacante controla, ao menos parcialmente, o endereço e/ou o valor de uma escrita de memória dentro do contexto do processo VMX. O VMX é o processo do host que emula dispositivos e faz a ponte entre a VM guest e o VMkernel — ele roda com privilégios elevados no host, mas ainda é isolado do kernel do hypervisor. A vulnerabilidade permite que essa escrita descontrolada atinja estruturas do kernel, corrompendo estado que o atacante usa para desviar execução ou elevar privilégios além do sandbox do VMX.
Como é explorada
O pré-requisito documentado pela Broadcom é ter 'privilégios dentro do processo VMX' — ou seja, o atacante já não está mais confinado à VM guest, e sim executando código no contexto do processo VMX do host. Isso normalmente é obtido como segundo estágio de uma cadeia: a Broadcom publicou CVE-2025-22225 junto com CVE-2025-22224 (heap overflow TOCTOU no VMCI, explorável por um usuário com privilégios administrativos locais na VM para executar código como o processo VMX do host) e CVE-2025-22226 (leitura fora de limites no HGFS, para leak de memória do VMX). A combinação plausível é: comprometer a VM com privilégios admin, usar CVE-2025-22224 para rodar código no VMX do host, e então usar CVE-2025-22225 para escrever no kernel do VMkernel e escapar completamente do sandbox de virtualização.
A Broadcom afirma ter informação de exploração in the wild para as três CVEs do advisory, e a CISA incluiu CVE-2025-22225 no KEV confirmando exploração ativa — sem detalhar o ator ou a campanha. O resultado final de uma cadeia completa é execução de código no VMkernel, comprometendo o hypervisor inteiro e, por extensão, todas as VMs hospedadas nele — o cenário mais grave possível em ambientes de virtualização multi-tenant.
Versões
Como se proteger
Não existe workaround publicado pela Broadcom para CVE-2025-22225 — a única remediação listada na matriz do VMSA-2025-0004 é aplicar o patch. Para ESXi 8.0 aplicar ESXi80U3d-24585383 (branch U3) ou ESXi80U2d-24585300 (branch U2); para ESXi 7.0 aplicar ESXi70U3s-24585291. Cloud Foundation 5.x e 4.5.x recebem os mesmos patches via patch assíncrono documentado na KB88287; Telco Cloud Platform (5.x/4.x/3.x/2.x) e Telco Cloud Infrastructure (3.x/2.x) seguem a KB389385.
Como não há mitigação de configuração, o controle compensatório realista é reduzir quem pode chegar ao pré-requisito: restringir e monitorar privilégios administrativos locais dentro das VMs guest (o que impede o primeiro estágio via CVE-2025-22224), já que sem esse acesso o atacante não alcança o contexto VMX necessário para explorar esta CVE. Isso não substitui o patch — apenas limita a superfície até a atualização ser aplicada.
Como detectar
As fontes consultadas não trazem indicadores de comprometimento, assinaturas de log ou padrões de tráfego específicos para esta CVE. Como a exploração ocorre inteiramente dentro do processo VMX no host (sem tráfego de rede envolvido no estágio descrito), a detecção depende de monitoramento de integridade e comportamento anômalo do processo vmx e do VMkernel — crashes inesperados, reinícios do processo VMX, ou anomalias em vmkernel.log e vmware.log da VM — mas nenhum desses sinais é confirmado pela Broadcom ou pela CISA como indicador confiável específico desta falha.