Uma vulnerabilidade crítica foi descoberta no vm2, biblioteca npm usada para executar JavaScript não confiável em ambientes isolados. A falha, identificada como CVE-2026-26956, permite que código malicioso fuja do sandbox e execute comandos diretamente no servidor — comprometendo todo o sistema host.
A gravidade foi classificada como 9.8 de 10 pelo sistema CVSS, o que a coloca na categoria crítica. A falha afeta a versão 3.10.4 do vm2 em ambientes que rodam Node.js 25. As informações são da SOC Radar.
O vm2 é uma biblioteca npm bastante popular no ecossistema Node.js. Ela foi criada para rodar código JavaScript não confiável dentro de um ambiente isolado, chamado de sandbox, basicamente um espaço separado do restante do sistema onde o código não deveria conseguir causar danos fora dos limites definidos.
Esse recurso é usado em plataformas que permitem que usuários ou terceiros rodem scripts. Pense em ferramentas de automação, plataformas de CI/CD, sistemas de plugins ou serviços que oferecem algum tipo de execução de código personalizado.
Como a falha funciona
O problema está na forma como o vm2 lida com exceções, ou seja, erros que ocorrem durante a execução do código. Normalmente, o vm2 intercepta esses erros e os processa dentro do próprio sandbox, impedindo que informações do ambiente externo vazem para dentro do espaço isolado.
A CVE-2026-26956 consegue contornar essa proteção usando recursos de tratamento de exceções do WebAssembly. O WebAssembly é uma tecnologia que permite rodar código de baixo nível diretamente no runtime do JavaScript, e a versão 25 do Node.js passou a incluir suporte a funcionalidades avançadas dessa tecnologia.
Um atacante pode usar construções específicas do WebAssembly para capturar um erro JavaScript antes que o vm2 consiga processá-lo. Isso significa que o erro chega ao código malicioso sem passar pelo filtro de segurança da biblioteca.
Com esse erro em mãos, o atacante percorre uma sequência de chamadas internas do JavaScript até alcançar o objeto process do host, que é basicamente a estrutura que representa o processo Node.js rodando no servidor.
O que acontece depois do escape
Uma vez fora do sandbox, o caminho mais comum é carregar o módulo child_process do Node.js. Esse módulo permite executar comandos do sistema operacional diretamente, o que equivale a ter acesso ao terminal do servidor.
Com isso, o atacante pode ler arquivos, acessar variáveis de ambiente que contenham senhas ou tokens de API, se mover pela rede interna e, dependendo das permissões do processo, comprometer outros sistemas conectados.
Quem está em risco
A falha afeta especificamente ambientes que combinam vm2 3.10.4 com Node.js 25, mais precisamente a versão v25.6.1 em Linux x64. O exploit depende do suporte a WebAssembly exception handling e WebAssembly.JSTag, funcionalidades presentes nessa versão do Node.
Quem usa versões anteriores do Node.js provavelmente não está exposto a essa CVE específica. Mas os pesquisadores alertam que isso não torna o vm2 seguro de forma geral, porque a biblioteca tem um histórico longo de falhas semelhantes.
O risco é mais alto em sistemas multi-tenant, onde usuários diferentes executam seus próprios scripts na mesma infraestrutura, e em serviços que tratam o vm2 como barreira de segurança contra entradas maliciosas.
Prova de conceito disponível e sem exploração confirmada
Um código de prova de conceito já foi publicado no próprio aviso de segurança da CVE. O PoC demonstra tanto o escape do sandbox quanto a execução de comandos no host, o que reduz consideravelmente o esforço técnico necessário para transformar a falha em um ataque real.
Até o momento, não há confirmação de exploração ativa nem registro da CVE no catálogo de vulnerabilidades conhecidas exploradas da CISA. Os pesquisadores recomendam não usar a ausência de exploração confirmada como motivo para adiar a correção.
O que fazer agora
A correção está disponível na versão 3.10.5 do vm2. A recomendação é atualizar imediatamente para essa versão ou para uma mais recente.
Mas atualizar pode não ser suficiente a longo prazo. Os próprios mantenedores do vm2 declararam oficialmente que o projeto está depreciado, ou seja, não receberá mais atualizações de segurança de forma contínua. A recomendação da comunidade é migrar para alternativas ativamente mantidas, como o isolated-vm.
Enquanto a migração não acontece, as boas práticas incluem isolar a execução de código não confiável em contêineres ou máquinas virtuais separadas, remover variáveis de ambiente sensíveis do contexto de execução e monitorar chamadas inesperadas ao child_process partindo de serviços que rodam código de terceiros.
Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.