Isolar JavaScript não confiável dentro do mesmo processo Node.js é, fundamentalmente, uma estratégia frágil.

Imagine uma biblioteca criada para isolar código malicioso. Agora imagine que ela virou a porta de entrada do atacante. Foi exatamente isso que pesquisadores da SOC Radar acabaram de revelar sobre o vm2. Trata-se de uma das bibliotecas mais populares do npm.

A falha foi registrada como CVE-2026-26956. Ela recebeu nota 9.8 de 10 no sistema CVSS. Além disso, já conta com prova de conceito pública circulando na internet.

Em outras palavras, primeiramente: o problema é grave. Além disso: o exploit é real. Sobretudo: ele afeta quem rodou o npm update recentemente para a versão mais nova do runtime.

O que torna essa CVE diferente das anteriores do vm2 (Node.js)

Antes de mais nada, vale entender o contexto. O vm2 sempre foi uma biblioteca controversa no ecossistema Node.js. Por um lado, ela resolve um problema legítimo: executar JavaScript não confiável em ambientes isolados. São os famosos sandboxes.

Por outro lado, seu histórico de vulnerabilidades é extenso. Tanto que muitos devs já migraram para alternativas como isolated-vm.

Contudo, a versão 3.10.4 segue amplamente utilizada. Ela aparece em plataformas de automação, sistemas de CI/CD e ferramentas de plugins. Também é comum em qualquer serviço que precise rodar scripts de terceiros. Consequentemente, o impacto potencial é enorme.

A novidade aqui é o vetor de ataque. Falhas anteriores exploravam proxies ou prototypes do JavaScript. Dessa vez, porém, o problema vem de uma fonte inesperada: o WebAssembly.

Como o WebAssembly virou a chave para escapar do sandbox

A versão 25 do Node.js trouxe suporte ampliado a recursos avançados de WebAssembly. Entre eles estão exception handling e a API WebAssembly.JSTag. Em teoria, isso é ótimo para quem desenvolve aplicações de alta performance. Entretanto, na prática, abriu uma brecha. O vm2 nunca foi projetado para fechá-la.

O mecanismo de proteção do vm2 funciona da seguinte forma. Sempre que uma exceção ocorre dentro do sandbox, a biblioteca intercepta esse erro. Em seguida, ela o processa internamente. Dessa maneira, impede que objetos do ambiente externo vazem para o código isolado. Em condições normais, esse filtro funciona bem.

Porém, com WebAssembly exception handling, o cenário muda. Um atacante consegue capturar um erro JavaScript antes que o vm2 processe. Logo depois, ao usar WebAssembly.JSTag, o código malicioso manipula esse erro. Então, ele segue por uma cadeia de chamadas internas. Por fim, alcança o objeto process do host.

A partir desse ponto, basicamente acabou.

Do escape do sandbox ao controle total do servidor

Uma vez fora do ambiente isolado, o atacante tem o ecossistema Node.js inteiro à disposição. O caminho mais comum, naturalmente, é carregar o módulo child_process. Com ele, executar comandos do sistema operacional é trivial. Em poucas linhas, o invasor opera como se estivesse no terminal do servidor.

A partir daí, as possibilidades são preocupantes:

• Leitura de arquivos sensíveis no sistema de arquivos
• Acesso a variáveis de ambiente contendo credenciais e tokens
• Movimentação lateral pela rede interna da infraestrutura
• Comprometimento de outros serviços que confiam no host vulnerável
• Instalação de backdoors persistentes, dependendo das permissões

Resumindo: é o pior cenário de execução remota de código em produção.

Quem precisa se preocupar agora com Node.js

A combinação exata que torna a exploração viável é bem específica. Trata-se do vm2 versão 3.10.4 rodando sob Node.js v25.6.1 em Linux x64. Os pesquisadores confirmaram a prova de conceito nesse ambiente.

Contudo, é razoável supor que outras builds do Node.js 25 também sejam afetadas. Isso vale desde que tenham suporte ativo a WebAssembly exception handling.

Por outro lado, quem ainda está em versões anteriores do Node.js provavelmente não está exposto. Isso inclui ambientes na 20 LTS ou na 22. Porém, atenção: isso não significa que o vm2 esteja seguro nessas versões. Pelo contrário. A biblioteca acumula tantas falhas históricas que, francamente, deveria estar sendo aposentada.

O que fazer hoje para mitigar o risco

Primeiramente, faça um inventário rápido. Rode na raiz do seu projeto:

npm ls vm2

Se o vm2 aparecer entre as dependências e seu ambiente roda Node.js 25, considere isso uma emergência. Em seguida, algumas ações práticas:

• Faça downgrade temporário para Node.js 22 LTS enquanto avalia a migração
• Desabilite o suporte a WebAssembly exception handling via flag, se possível
• Migre para isolated-vm, que usa isolamento real via V8 isolates
• Avalie alternativas como Cloudflare Workers para execução de código não confiável

Adicionalmente, monitore os logs. Procure por chamadas suspeitas a child_process. Especialmente aquelas originadas de contextos que deveriam estar sandboxed. Caso encontre algo, presuma comprometimento. Em seguida, siga seu plano de resposta a incidentes.

A lição que o vm2 continua nos ensinando

Por fim, vale uma reflexão maior. O vm2 surgiu como solução para um problema legítimo. Contudo, sua arquitetura sempre dependeu de manter o sandbox um passo à frente. Isso vale tanto para novidades do JavaScript quanto do Node.js. A cada nova feature do runtime, uma nova superfície de ataque aparece. Em consequência, o ciclo de descoberta de falhas parece não ter fim.

Portanto, se você ainda usa vm2 em produção, talvez seja hora de encarar uma verdade incômoda. Soluções baseadas em isolamento de processo ou contêineres oferecem garantias mais sólidas. Runtimes especializados também são uma opção robusta.

A CVE-2026-26956 é apenas o lembrete mais recente. Provavelmente, não será o último.

Acompanhe nosso perfil no Instagram!