Falha crítica de sandbox no vm2 permite que código não confiável escape para o host

Os mantenedores do vm2, uma biblioteca de sandbox para Node.js amplamente usada, divulgaram uma vulnerabilidade crítica que pode permitir que JavaScript não confiável escape de seu sandbox e execute código na máquina host. A falha é rastreada como CVE-2026-26956, afeta o vm2 versão 3.10.4 e chega com código exploit de prova de conceito já disponível publicamente.

Isso importa porque o vm2 é uma das ferramentas padrão às quais os desenvolvedores recorrem quando precisam executar JavaScript fornecido por usuários dentro de um ambiente supostamente restrito. Ele aparece em plataformas de programação online, produtos de automação, ferramentas de AI e aplicações SaaS que permitem aos clientes executar scripts. Quando um escape de sandbox surge em software como esse, o problema não é um bug teórico elegante. É uma questão direta sobre se código não confiável de um locatário pode se transformar em comprometimento no nível do host.

De acordo com o advisory do mantenedor e a reportagem da BleepingComputer, o bug está ligado à forma como o vm2 trata exceções que cruzam entre o sandbox e o host. Na configuração afetada, o WebAssembly exception handling pode contornar as proteções do vm2 no nível de JavaScript dentro do mecanismo V8. Isso pode permitir que um objeto de erro do lado do host vaze de volta para o sandbox, onde atacantes podem abusar da cadeia de constructor para recuperar acesso a componentes internos do Node.js, como o process object, e finalmente executar comandos arbitrários no host.

A exposição não é universal em toda implantação de Node.js. O advisory diz que o problema foi confirmado no Node.js 25.6.1 em ambientes com WebAssembly exception handling e suporte a JSTag habilitados. Esse escopo técnico importa, mas não deve criar uma falsa sensação de conforto. O vm2 é baixado mais de um milhão de vezes por semana no npm, e bibliotecas como essa muitas vezes ficam enterradas profundamente dentro de produtos maiores, ferramentas internas ou recursos de extensibilidade para clientes que as equipes não inventariam com o cuidado necessário.

O detalhe mais urgente é que o código exploit já é público. Quando um escape de sandbox tem tanto um CVE quanto uma prova de conceito pública, a distância entre a divulgação e a exploração oportunista tende a encolher rapidamente, especialmente em serviços expostos à internet que executam workflows de usuários, trechos de código ou etapas de automação. Se uma empresa usa vm2 para isolar lógica não confiável, precisa assumir que atacantes vão testar essa fronteira agora, não depois.

O caminho de patch é direto. Os usuários devem sair imediatamente do vm2 3.10.4 e atualizar para a versão 3.10.5 ou posterior, com a 3.11.2 disponível atualmente. Mas aplicar o patch sozinho não é toda a resposta. As equipes também devem identificar onde o vm2 está embutido, confirmar se as configurações afetadas do Node.js 25 estão em uso e revisar quaisquer superfícies de produto em que usuários externos possam enviar código que eventualmente chegue a um sandbox vm2.

Essa divulgação também se encaixa em um padrão mais amplo. O vm2 foi atingido por vários bugs graves de escape de sandbox nos últimos anos, o que levanta uma pergunta de engenharia difícil, mas cada vez mais importante: quanta isolação real um sandbox de JavaScript oferece quando atacantes começam a encontrar caminhos para contornar defesas no nível da linguagem? Para equipes que constroem plataformas sobre código executado por usuários, essa pergunta está se tornando arquitetural, e não incidental. Como reportado primeiro pela BleepingComputer, a resposta mais segura aqui não é apenas aplicar o patch rapidamente, mas reavaliar quanta confiança está sendo depositada no vm2 em primeiro lugar.