Em ambos os casos, os usuários de maior risco são organizações que executam JavaScript não confiável e presumem que o vm2 o contém. Essas equipes (de desenvolvimento de aplicativos) devem corrigir imediatamente e adicionar um isolamento mais forte em torno das cargas de trabalho em sandbox.”
‘Modelo de segurança frágil’
Essas vulnerabilidades de escape de sandbox demonstram por que colocar código não confiável dentro de um processo confiável é um modelo de segurança frágil, disse Adam Reynolds, pesquisador sênior de segurança da Sonatype, por e-mail. “Uma vez que o código não confiável é executado dentro de um processo com acesso a credenciais e segredos, ao sistema de arquivos subjacente, à rede ou com privilégios de implantação, um bypass de sandbox pode facilmente levar ao comprometimento total do sistema”, disse ele.
Simplesmente ter o vm2 instalado em algum lugar da árvore de dependências não é suficiente para tornar algumas dessas vulnerabilidades exploráveis, acrescentou. Por exemplo, um invasor geralmente precisa da capacidade de executar JavaScript criado (e, no caso de CVE-2026-26956, WebAssembly criado) dentro de uma sandbox vm2 controlada pelo aplicativo vulnerável. Se o aplicativo nunca instanciar o vm2, usá-lo apenas para scripts internos confiáveis ou não permitir a execução de código controlado pelo invasor, poderá não haver um caminho de exploração realista, apesar da presença da dependência.
