Duas falhas críticas no Wasmtime, um ambiente de execução de WebAssembly que pode ser incorporado a outros softwares, podem permitir que um módulo WebAssembly malicioso escape do sandbox (ambiente isolado destinado a contê-lo), segundo os mantenedores do projeto.
Um invasor precisaria, antes, de uma versão vulnerável do Wasmtime para compilar um módulo sob seu controle, e uma das falhas afeta apenas sistemas ARM64. As versões corrigidas foram lançadas em 19 e 20 de outubro, e os mantenedores não relataram nenhum ataque.
O Wasmtime executa código WebAssembly fora de navegadores da web. Ambas as falhas estão no Cranelift, o compilador usado por padrão para transformar WebAssembly em código de máquina. Os mantenedores do Wasmtime, na Bytecode Alliance, atribuíram a cada falha nota 9,9 em 10 na escala CVSS (Common Vulnerability Scoring System, ou sistema de pontuação de vulnerabilidades comuns) nos avisos publicados em 19 de outubro.
- CVE-2026-115889 (sigla de Common Vulnerabilities and Exposures, identificador padrão de vulnerabilidades) afeta o Wasmtime em todas as arquiteturas de processador.
- CVE-2026-115893 afeta apenas ARM64, também chamada aarch64.
O sandbox foi projetado para manter um módulo dentro de limites definidos. Um módulo só pode usar a própria memória e as funções do host que lhe são fornecidas, e seu código só pode saltar para locais verificados.
Como ambas as falhas exigem um módulo controlado pelo invasor, o risco é maior para serviços que compilam módulos escritos por terceiros. A Fastly, por exemplo, afirma que sua plataforma Compute executa código de clientes usando o Wasmtime. Os avisos não citam nenhum serviço afetado nem especificam o que um invasor poderia acessar após escapar do sandbox.
Nenhuma das duas falhas constava, até 26 de outubro, no catálogo Known Exploited Vulnerabilities (KEV), mantido pela U.S. Cybersecurity and Infrastructure Security Agency (CISA).
Quais versões são afetadas
As duas falhas foram corrigidas em momentos diferentes, portanto a exposição depende da linha de versão em uso e, no caso de uma delas, da arquitetura do processador.
O Wasmtime oferece versões de suporte de longo prazo (LTS, sigla de long-term support), numeradas em múltiplos de 12, por dois anos. As demais versões recebem suporte por dois meses. Correções de segurança são garantidas para as versões com suporte.
Apenas as linhas 36, 48, 49 e 50 ainda têm suporte. Todas as outras, incluindo a linha LTS 24.x, cujo suporte terminou em 20 de agosto de 2026, não receberam correção.
Hosts ARM64 que foram atualizados para 36.0.7, 42.0.2 ou 43.0.1 em abril, para corrigir uma falha anterior de escape de sandbox do Cranelift em ARM64, continuam afetados pelo CVE-2026-115893.
O que fazer
Atualize para a versão corrigida da sua linha: 36.0.19, 48.0.7 ou 49.0.4. O Wasmtime 50.0.0, lançado em 20 de outubro, corrige as duas falhas. Hosts em linhas sem suporte precisam migrar para uma dessas versões.
Como o Wasmtime pode ser incorporado a outros programas como biblioteca, atualizar apenas a ferramenta de linha de comando não corrige as falhas. Cada programa que inclui o Wasmtime precisa ser recompilado com uma versão corrigida.
Nenhum dos avisos indica solução alternativa. Enquanto um host não for atualizado, o risco vem de qualquer módulo que alguém de fora possa fornecer.
Ambas as falhas constam no RustSec, a base de dados usada pela ferramenta cargo-audit para verificar arquivos Cargo.lock, como RUSTSEC-2026-0380 e RUSTSEC-2026-0379.
Até 26 de outubro, a base de dados de avisos do GitHub tinha uma entrada revisada para o CVE-2026-115889, mas nenhuma para o CVE-2026-115893. O GitHub informa que apenas entradas revisadas disparam alertas do Dependabot, então usuários do Dependabot não devem esperar um alerta para a falha em ARM64.
O Spin, ferramenta de código aberto para criar aplicações WebAssembly sem servidor (serverless) que roda sobre o Wasmtime, migrou para o Wasmtime 50.0.0 na versão 4.2.4 em 21 de outubro.
Como funcionam as duas falhas
O CVE-2026-115889 decorre da forma como o Cranelift armazenava os números que usa para acompanhar valores dentro de uma função. Antes da versão 43, ele empacotava esses números em campos de 24 bits e, nas compilações de release, um número grande demais para seu campo transbordava sem gerar nenhum erro.
Assim, o Cranelift podia referenciar o valor errado, gerando código de máquina incorreto. Uma função WebAssembly muito grande, ou construída para usar muitos valores, pode explorar isso para forçar uma confusão de tipos e escapar do sandbox, segundo o aviso.
A linha principal de desenvolvimento do Wasmtime já havia eliminado o problema. Uma mudança integrada em 18 de fevereiro ampliou os campos para 32 bits e foi incluída no Wasmtime 43.0.0, lançado em 20 de março. A descrição a apresentava como uma forma de compilar funções maiores e não mencionava segurança.
A linha LTS 36.x recebeu a mesma mudança em 19 de outubro. O aviso não informa quando o impacto para a segurança foi reconhecido.
O CVE-2026-115893 envolve o br_table, uma instrução do WebAssembly que salta para um entre vários pontos do código com base em um índice. Um índice fora da tabela leva a um destino padrão. Em ARM64, o Cranelift enviava esses índices fora do intervalo para o destino padrão por meio de um desvio que só alcança cerca de 1 MiB (mebibyte).
Um br_table com mais de cerca de 256.000 destinos tornava a tabela de saltos grande demais para esse alcance, e o desvio apontava silenciosamente para o lugar errado.
Qualquer mecanismo de execução (engine) do Wasmtime em ARM64 com configurações padrão “pode ser forçado a saltar para código arbitrário por um módulo Wasm controlado pelo usuário”, afirma o aviso. O problema existe desde que o Wasmtime passou a oferecer suporte a ARM64, em 2020.
A correção envia os índices fora do intervalo pela própria tabela de saltos, de modo que não é necessário um desvio longo. As versões corrigidas também se recusam a compilar um br_table com mais de 65.520 destinos.
