Falhas críticas no `vm2` permitem escape de sandbox e execução de código em hosts Node.js

Doze vulnerabilidades no mecanismo de isolamento da biblioteca vm2 expõem aplicações que executam JavaScript não confiável a escape de sandbox, carregamento de módulos bloqueados e execução de comandos no sistema subjacente.

Componente	Biblioteca open source vm2 para execução de JavaScript não confiável em sandbox no Node.js, incluindo usos de NodeVM e mecanismos de proxy/interceptação de objetos.
Vetor	Código JavaScript controlado pelo atacante executado dentro da sandbox aciona falhas em propriedades, coerções, exceções, introspecção, protótipos ou allowlists internas para alcançar objetos do host.
Impacto	Escape da sandbox e execução de código ou comandos no host subjacente; em um caso, carregamento de built-ins excluídos como child_process; em outro, prototype pollution associada ao escape.
Prioridade	Atualizar vm2 para 3.11.2, localizar serviços que aceitam scripts ou expressões de usuários, revisar isolamento em nível de processo/contêiner e procurar execução anômala de processos filhos a partir de runtimes Node.js.
Versões	CVE-2026-26956 afeta 3.10.4, confirmado em Node.js 25.6.1 e corrigido em 3.10.5; CVE-2026-43999 afeta 3.10.5 e foi corrigido em 3.11.0; CVE-2026-44005 afeta 3.9.6 a 3.10.5 e foi corrigido em 3.11.0; a recomendação consolidada é 3.11.2.
Artefatos	CVE-2026-24118, CVE-2026-24120, CVE-2026-24781, CVE-2026-26332, CVE-2026-26956, CVE-2026-43997, CVE-2026-43999, CVE-2026-44005, CVE-2026-44006, CVE-2026-44007, CVE-2026-44008 e CVE-2026-44009.

Resumo técnico

A biblioteca vm2, usada para executar JavaScript não confiável em uma sandbox no ecossistema Node.js, teve doze vulnerabilidades críticas divulgadas com impacto concentrado em escape de sandbox e execução de código no host. O modelo de segurança do componente depende da interceptação, encapsulamento e mediação de objetos JavaScript para impedir que o código isolado alcance referências do ambiente externo. As falhas mostram diferentes caminhos para romper essa barreira: acesso indireto a objetos do host, abuso de propriedades de promises, comportamento de funções de inspeção, manipulação de exceções, coerção de tipos, bypass de allowlist em NodeVM, prototype pollution e injeção de código em handlers internos.

O risco real depende de como a aplicação usa vm2. Ambientes que avaliam scripts enviados por usuários, plugins de terceiros, regras dinâmicas, automações, fórmulas, templates ou código de extensões ficam mais expostos, porque o atacante já começa com a capacidade de fornecer JavaScript para execução dentro da sandbox. Quando a aplicação executa esse código no mesmo processo que segredos, variáveis de ambiente, credenciais de serviços, clientes de banco de dados ou permissões de sistema, o escape transforma uma fronteira lógica em ponto de execução no host. Em casos com acesso a child_process ou execução de comandos do sistema operacional, a consequência deixa de ser apenas leitura de objetos internos e passa a permitir ações diretas no ambiente subjacente.

Fluxo técnico

As falhas exploram o fato de que a sandbox precisa expor ao código não confiável partes suficientes da linguagem JavaScript para que scripts funcionem, mas sem deixar que essas referências retornem ao contexto privilegiado. CVE-2026-24118 envolve escape por __lookupGetter__, o que indica abuso de introspecção de propriedades para contornar a mediação esperada. CVE-2026-24120 é descrita como bypass de correção para CVE-2023-37466, com escape por meio da propriedade species de objetos promise, permitindo que a lógica de construção ou propagação de promises atravesse a fronteira prevista. CVE-2026-24781 usa a função inspect, área sensível porque rotinas de representação e depuração frequentemente recebem objetos atravessando contextos diferentes.

Outros caminhos passam por exceções e coerção. CVE-2026-26332 permite escape por SuppressedError, enquanto CVE-2026-26956 ocorre quando uma coerção de Symbol para string gera um TypeError que falha como mecanismo de proteção, com execução arbitrária de código após o escape. A vulnerabilidade foi confirmada em vm2 3.10.4 com Node.js 25.6.1 e corrigida em 3.10.5, o que torna esse caso particularmente útil para inventário: a versão exata do pacote e do runtime deve ser conferida em artefatos de build, imagens de contêiner e lockfiles.

A lista também inclui falhas de injeção e controle de acesso. CVE-2026-43997 permite obter o Object do host e escapar da sandbox, com pontuação CVSS 10.0. CVE-2026-43999 ignora a allowlist interna de NodeVM e permite carregar built-ins excluídos, incluindo child_process, criando um caminho direto para execução remota de código quando a interface vulnerável é acessível por rede. CVE-2026-44005 combina JavaScript controlado pelo atacante com escape de sandbox e prototype pollution, afetando 3.9.6 a 3.10.5. CVE-2026-44006 envolve injeção de código por BaseHandler.getPrototypeOf. CVE-2026-44007 é uma falha de controle de acesso impróprio que permite execução de comandos do sistema operacional. CVE-2026-44008 passa por neutralizeArraySpeciesBatch(), e CVE-2026-44009 usa uma exceção com protótipo nulo.

Superfície afetada

A superfície principal são aplicações Node.js que incorporam vm2 para aceitar e executar JavaScript de origem não totalmente confiável. Isso inclui plataformas de automação, sistemas de regras customizadas, avaliadores de expressões, ambientes de plugin, produtos de análise que permitem transformações escritas pelo usuário, serviços de treinamento que rodam snippets e backends que usam sandbox como limite de segurança entre tenants. A existência da dependência no package.json não confirma exploração, mas indica que o fluxo de execução precisa ser mapeado até o ponto em que entradas externas chegam à sandbox.

O impacto aumenta quando o processo Node.js possui privilégios além do estritamente necessário. Variáveis de ambiente com tokens, credenciais de nuvem, chaves de banco, sockets internos, permissões de escrita em diretórios sensíveis ou acesso de rede a planos de controle tornam o escape mais danoso. Mesmo quando a aplicação roda em contêiner, a sandbox de linguagem não deve ser tratada como único limite: se o contêiner tiver montagem de volumes, credenciais de workload, acesso a metadados de nuvem ou perfil permissivo, o atacante que executa código no processo pode tentar transformar a execução local em movimentação para dados ou serviços internos.

• Serviços que recebem scripts, fórmulas, templates, regras ou plugins de usuários e os executam com vm2.
• Ambientes com NodeVM configurado para bloquear built-ins, porque CVE-2026-43999 permite bypass dessa allowlist em versão afetada.
• Builds com vm2 3.10.4, 3.10.5 ou faixa 3.9.6 a 3.10.5, conforme os casos com versão explicitamente informada.
• Processos Node.js que carregam segredos em variáveis de ambiente, executam com permissões amplas ou compartilham rede com bancos, filas, APIs internas e serviços de nuvem.

Hunting e telemetria

A investigação deve começar pelo inventário de dependências e pela confirmação de caminhos de execução. Procure vm2 em package-lock.json, yarn.lock, pnpm-lock.yaml, manifests de SBOM, imagens de contêiner e caches de CI/CD. Depois, relacione cada ocorrência com rotas, filas, tarefas assíncronas ou workers que aceitam conteúdo controlado por usuário. O ponto crítico é diferenciar dependência transitiva sem uso exposto de sandbox usada como fronteira de segurança em fluxo ativo.

Em endpoints e servidores, a telemetria mais útil é a correlação entre requisições que submetem código ou expressões e eventos de processo inesperados. Carregamento de child_process, invocações de exec, spawn ou fork, execução de shells, leitura incomum de variáveis de ambiente e conexões de saída iniciadas logo após avaliação de scripts devem ser tratados como sinais fortes. Logs de aplicação podem conter erros de TypeError, exceções relacionadas a Symbol, acessos a inspect, falhas de promises ou mensagens de política de built-ins, mas a ausência desses registros não elimina exploração, porque um payload bem-sucedido pode evitar ruído ou limpar artefatos em nível de aplicação.

Para ambientes em contêiner e nuvem, procure execução de comandos por processos Node.js que normalmente só deveriam interpretar lógica de negócio. Em Kubernetes, eventos de criação de processos dentro do contêiner, conexões para metadados, tentativas de leitura de service account tokens e tráfego para endpoints internos após submissão de scripts merecem prioridade. Em pipelines, verifique se testes, runners ou ferramentas internas executam snippets com vm2, pois um pacote ou contribuição maliciosa pode acionar a sandbox durante build, lint, documentação ou geração de artefatos.

• Ocorrência de vm2 em lockfiles, SBOMs, imagens de contêiner, caches de dependências e artefatos de build.
• Processos filhos iniciados por node em serviços que deveriam apenas avaliar JavaScript isolado.
• Uso inesperado de child_process, comandos de sistema, shells ou conexões de saída após entradas de usuário processadas pela sandbox.
• Erros ou exceções associados a TypeError, Symbol, inspect, SuppressedError, promises e protótipos durante execução de scripts não confiáveis.
• Alterações anômalas de comportamento após prototype pollution, como propriedades herdadas inesperadas em objetos usados por autorização, roteamento ou serialização.

Mitigação

A ação principal é atualizar vm2 para 3.11.2 em todos os serviços que dependem da biblioteca, reconstruir artefatos e redeployar imagens que carregam versões antigas. A atualização precisa alcançar lockfiles e ambientes empacotados; alterar apenas o manifesto sem regenerar package-lock.json, yarn.lock ou pnpm-lock.yaml pode deixar a versão vulnerável em produção. Para os casos com correção intermediária, 3.10.5 resolve CVE-2026-26956 e 3.11.0 resolve CVE-2026-43999 e CVE-2026-44005, mas a versão consolidada indicada para proteção é 3.11.2.

A correção de pacote deve ser acompanhada de redução de impacto. Serviços que executam código não confiável devem rodar com usuário sem privilégio, filesystem restrito, sem segredos desnecessários no ambiente, sem acesso amplo à rede interna e com isolamento operacional fora da sandbox de linguagem. Quando possível, mova a execução para processo separado, contêiner dedicado ou worker com política de rede mínima e tempo de execução limitado. A sandbox JavaScript deve ser uma camada de contenção, não o único controle impedindo acesso a dados, credenciais ou plano de controle.

Após a atualização, valide com inventário e observabilidade. Confirme que nenhum build antigo permaneceu ativo, revise registros de execução antes da correção, procure comandos disparados por Node.js e rotacione credenciais acessíveis ao processo quando houver indício de exploração. Se a aplicação expunha interface pública para scripts, trate tentativas suspeitas como possível execução no host até que logs de processo, rede, identidade e aplicação indiquem o contrário.

• Atualizar vm2 para 3.11.2 e regenerar lockfiles antes de reconstruir imagens e pacotes de produção.
• Mapear todas as entradas de usuário que chegam a vm2, incluindo APIs, filas, painéis administrativos, plugins, tarefas agendadas e ferramentas internas.
• Executar workers de sandbox com usuário sem privilégio, variáveis de ambiente mínimas, rede restrita, filesystem limitado e tempo de execução controlado.
• Monitorar e bloquear execução inesperada de processos filhos por runtimes Node.js que processam código não confiável.
• Rotacionar credenciais expostas ao processo se houver sinais de escape, execução de comandos, leitura de ambiente ou conexões de saída não previstas.