Vulnerabilidade crítica em vm2 (CVE-2026-26956): rompe a sandbox e permite executar comandos no host com Node.js 25

Uma falha crítica na biblioteca de sandboxing para Node.js vm2 —registrada como CVE-2026-26956 — permite a código malicioso escapar da gaiola e executar comandos arbitrários no host. A vulnerabilidade foi confirmada pelo menos na versão 3.10.4 e o mantenedor publicou um exploit de teste de conceito, o que converte o achado em uma ameaça prática para serviços que executam código de terceiros em tempo real.

vm2 é amplamente utilizada em plataformas de aprendizagem, editores on-line, máquinas e aplicativos SaaS que aceitam e executam scripts de usuários, com mais de 1.3 milhões de downloads semanais em npm. A mecânica da falha não é um clássico bypass de permissões em JavaScript: a livraria confia em protecções ao nível de JavaScript - emvoltórios (Proxies) e saneamento de objetos entre contextos - mas a gestão de excepções ao nível WebAssembly em V8 Permite interceptar erros antes de essas protecções agirem. De acordo com o aviso oficial, o vetor explora a conversão símbolo→ sequência para provocar um TypeError especialmente construído que faz com que um objeto de erro do lado do host "se filtre" ao sandbox sem ser saneado; desde essa instância corrupta os atacantes podem percorrer a cadeia de construtores e alcançar internals comoprocess, abrindo a porta para execução remota.

É importante salientar que o mantenedor indica que o problema foi reproduzido em ambientes com Node.js 25 (verificado em 25.6.1) Quando as funções de gestão de excepções WebAssembly e JSTag estão ativadas. No entanto, dado que o vm2 sofreu vulnerabilidades de escape de sandbox repetidas em anos recentes, o aparecimento de exploits públicos e a complexidade do ecossistema V8 aumentam o risco de descobertas adicionais ou de cadeias de exploração.

As consequências práticas para organizações que dependem de vm2 são claras: uma exploração remota pode derivar em exfiltração de dados, acesso a segredos em memória ou disco, movimentos laterais desde servidores que executam sandboxes, e além de comprometimento da pipeline de integração se esses ambientes processam código de terceiros. O histórico de vulnerabilidades prévias em vm2 reforça a necessidade de não confiar apenas em controles de isolamento implementados em nível de linguagem.

Para mitigar o risco de forma imediata e pragmática, a recomendação direta é atualizar a vm2 versão 3.10.5 ou superior(o mantenedor publicou a correção no repositório; ver o aviso técnico no GitHub e as releases). Se não for possível aplicar imediatamente o adesivo, avaliar desactivar as funcionalidades do WebAssembly exception handling e JSTag em ambientes afetados, evitar executar o vm2 em Node.js 25 até confirmar a configuração segura ou remover temporariamente a execução de código sem revisão. A página de manutenção contém tanto a advisoria com detalhes técnicos como os artefatos da release 3.10.5 Eles corrigem a falha.

Para além do adesivo, é conveniente aplicar princípios de redução de superfície e defesa em profundidade: correr sandboxes em processos isolados com mínimos privilégios do sistema operacional, conter com contêineres ou VMs dedicados, aplicar controles de rede e políticas de egress rigorosos, usar mecanismos de controle de recursos (cgroups, limites de CPU/memoria) e minimizar a exposição de segredos nos ambientes de execução. Também é recomendável instrumentar detecção e resposta a comportamentos anormais (execução de comandos do sistema, acesso a rotas sensíveis) e rotar credenciais que possam ter sido acessíveis a partir de sandboxes comprometidos.

Para equipamentos de desenvolvimento e segurança que gerem dependências, convém auditar onde se utiliza vm2 dentro de repositórios e pipelines, fixar versões no gestor de pacotes, adicionar verificações de segurança na CI para detectar e bloquear versões vulneráveis, e coordenar testes de vulnerabilidade incluindo a análise do PoC publicada para compreender o alcance no seu ambiente. Dada a rapidez com que surgiram exploits públicos, assumir um modelo de responsabilidade partilhada entre maintainers e consumidores é essencial.

Este incidente destaca duas lições: primeiro, que alcançar um isolamento robusto em ambientes JavaScript é complexo e frágil quando interage com camadas mais profundas do motor de execução; e segundo, que as organizações não devem depender apenas de sandboxing a nível de linguagem para executar código não confiável. Manter as dependências actualizadas, aplicar adesivos rapidamente e tomar medidas de contenção adicionais são as acções que reduzem significativamente o risco até que a arquitectura de execução possa ser restabelecida com controlos mais sólidos.