Duas falhas críticas no Wasmtime, um mecanismo de execução de WebAssembly que pode ser incorporado a outros programas, poderiam permitir que um módulo malicioso escapasse do sandbox criado para contê-lo, segundo os responsáveis pelo projeto.
Para explorar as falhas, um invasor precisaria usar uma versão vulnerável do Wasmtime para compilar um módulo sob seu controle. Uma das vulnerabilidades afeta apenas sistemas ARM64. As versões corrigidas foram lançadas em 19 e 20 de outubro, e os responsáveis pelo projeto não relataram ataques.
O Wasmtime executa código WebAssembly fora dos navegadores. As duas falhas estão no Cranelift, o compilador usado por padrão para transformar WebAssembly em código de máquina. Em comunicados publicados em 19 de outubro, os responsáveis pelo Wasmtime na Bytecode Alliance atribuíram nota 9,9 de 10 na escala CVSS a cada falha.
- A
CVE-2026-115889
afeta o Wasmtime em todas as arquiteturas de processador.
- A
CVE-2026-115893
afeta apenas sistemas ARM64, também conhecida como aarch64.
O sandbox deve manter cada módulo dentro de limites definidos. Um módulo só pode acessar a própria memória e as funções do sistema hospedeiro que lhe forem disponibilizadas. Além disso, o código só pode saltar para locais verificados.
Como as duas 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, informa que sua plataforma Compute executa código de clientes usando o Wasmtime. Os comunicados não identificam serviços afetados nem especificam quais recursos um invasor poderia acessar depois de escapar do sandbox.
Em 26 de outubro, nenhuma das falhas constava no catálogo Known Exploited Vulnerabilities (KEV), mantido pela Cybersecurity and Infrastructure Security Agency (CISA).
Quais versões são afetadas
As falhas foram corrigidas em momentos diferentes. Por isso, a exposição depende da linha de versões utilizada e, no caso de uma delas, da arquitetura do processador.
| Versão do Wasmtime |
CVE-2026-115889
, todas as arquiteturas |
CVE-2026-115893
, somente ARM64 | O que fazer |
|---|---|---|---|
| Anterior à 36.0.19, incluindo 24.x | Afetada | Afetada | Atualizar para a 36.0.19 ou migrar para a 48.0.7, 49.0.4 ou 50.0.0 |
| 36.0.19 | Corrigida | Corrigida | Nenhuma ação necessária para essas falhas |
| Da 37.0.0 até a série 42.x | Afetada | Afetada | Migrar para a 48.0.7, 49.0.4 ou 50.0.0 |
| Da 43.0.0 até a série 47.x | Não afetada | Afetada | Migrar para a 48.0.7, 49.0.4 ou 50.0.0 |
| Da 48.0.0 à 48.0.6 | Não afetada | Afetada | Atualizar para a 48.0.7 |
| 48.0.7 | Não afetada | Corrigida | Nenhuma ação necessária para essas falhas |
| Da 49.0.0 à 49.0.3 | Não afetada | Afetada | Atualizar para a 49.0.4 |
| 49.0.4 e 50.0.0 ou posterior | Não afetada | Corrigida | Nenhuma ação necessária para essas falhas |
O Wasmtime oferece versões com suporte de longo prazo (LTS), identificadas por números múltiplos de 12 e mantidas por dois anos. As demais versões recebem suporte por dois meses. As correções de segurança são garantidas para as versões ainda suportadas.
Somente as linhas 36, 48, 49 e 50 continuam com suporte. As demais não receberam correção, incluindo a linha LTS 24.x, cujo suporte terminou em 20 de agosto de 2026.
Sistemas ARM64 atualizados em abril para as versões 36.0.7, 42.0.2 ou 43.0.1, a fim de corrigir uma falha anterior no sandbox do Cranelift para ARM64, continuam vulneráveis à
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. Sistemas que usam uma linha sem suporte devem migrar para uma dessas versões.
O Wasmtime pode ser incorporado a outros programas como biblioteca. Por isso, atualizar a ferramenta de linha de comando não é suficiente: cada programa que inclui o Wasmtime precisa ser recompilado com uma versão corrigida.
Nenhum dos comunicados apresenta uma medida alternativa. Até que o sistema hospedeiro seja atualizado, o risco está relacionado a qualquer módulo que possa ser fornecido por terceiros.
As duas falhas estão registradas no RustSec, banco de dados usado pela ferramenta cargo-audit para verificar arquivos Cargo.lock. Os identificadores são RUSTSEC-2026-0380 e RUSTSEC-2026-0379.
Em 26 de outubro, o banco de dados de comunicados do GitHub tinha um registro analisado para a
CVE-2026-115889
, mas não para a
CVE-2026-115893
. O GitHub informa que apenas registros analisados geram alertas do Dependabot. Portanto, usuários do Dependabot não devem esperar um alerta sobre a falha que afeta ARM64.
O Spin, ferramenta open source para criar aplicações WebAssembly sem servidor que utiliza o Wasmtime, passou a usar o Wasmtime 50.0.0 na versão 4.2.4, lançada em 21 de outubro.
Como funcionam as falhas
A
CVE-2026-115889
decorre da forma como o Cranelift armazenava os números usados para acompanhar valores dentro de uma função. Antes da versão 43, esses números eram compactados em campos de 24 bits. Nas versões de produção, um número maior do que a capacidade do campo ultrapassava o limite sem gerar erro.
Com isso, o Cranelift podia referenciar o valor errado e produzir código de máquina incorreto. Segundo o comunicado, uma função WebAssembly muito grande ou que usasse muitos valores poderia explorar essa condição para provocar confusão de tipos e escapar do sandbox.
A linha principal de desenvolvimento do Wasmtime já havia eliminado o problema. Uma alteração incorporada em 18 de fevereiro ampliou os campos para 32 bits e foi incluída no Wasmtime 43.0.0 em 20 de março. A descrição da alteração a apresentava como uma forma de compilar funções maiores, sem mencionar implicações de segurança.
A linha LTS 36.x recebeu a mesma alteração em 19 de outubro. O comunicado não informa quando o impacto sobre a segurança foi identificado.
A
CVE-2026-115893
envolve a instrução br_table do WebAssembly, que salta para um entre vários locais do código com base em um índice. Se o índice estiver fora da tabela, a instrução direciona a execução para um destino padrão. Em sistemas ARM64, o Cranelift encaminhava esses índices para o destino padrão por meio de um salto cujo alcance máximo era de cerca de 1 MiB.
Uma br_table com mais de aproximadamente 256.000 destinos fazia a tabela de saltos ultrapassar esse alcance. Como resultado, o salto podia apontar silenciosamente para o local errado.
Segundo o comunicado, “qualquer runtime do Wasmtime em ARM64 com as configurações padrão pode ser forçado a saltar para código arbitrário por um módulo Wasm controlado por um usuário”. A falha existe desde que o Wasmtime passou a oferecer suporte a ARM64, em 2020.
A correção encaminha os índices fora do limite pela própria tabela de saltos, eliminando a necessidade de um salto de longo alcance. As versões corrigidas também impedem a compilação de uma br_table com mais de 65.520 destinos.
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...