Wasmtime corrige duas falhas graves em Cranelift (CVE-2026-115889, CVE-2026-115893)

Nas últimas semanas foram corrigidas duas falhas graves em Wasmtime, o ambiente de execução da WebAssembly que se integra em programas fora do navegador. Os mantenedores classificaram cada vulnerabilidade com 9,9/10 na escala CVSS e publicaram adesivos entre 19 e 20 de outubro. Os erros permitem, em determinadas condições, que um módulo WebAssembly malicioso escape do sandbox que deveria limitar e executar código fora da sua área autorizada. Segundo as notas oficiais, não há relatos públicos de exploração ativa até a data de corte indicada nos avisos.

O que está confirmado: As duas falhas são implementacionais em Cranelift, o compilador por defeito que Wasmtime usa para converter Wasm em código máquina. Estão registradas como CVE-2026-115889 (afecta todas as arquiteturas) e CVE-2026-115893 (afecta apenas a ARM64/aarch64). Os mantenedores publicaram versões corrigidas (por exemplo, Wasmtime 50.0.0 e adesivos pontuais nas linhas suportadas) que eliminam as condições vulneráveis. Além disso, ambas as entradas figuram na base de vulnerabilidades RustSec sob os identificadores mencionados, e o catálogo de vulnerabilidades exploradas conhecido por CISA não incluía estas CVE a 26 de outubro.

Como funcionam tecnicamente as falhas (resumo técnico verificável): CVE-2026-115889 vem de como Cranelift codificava internamente números usados para identificar valores dentro de uma função: originalmente esses identificadores se ajustavam em campos de 24 bits e, em compilações de lançamento, um identificador que excedia esse espaço transbordava sem detecção, o que poderia fazer com que o compilador transmitisse ao valor errado e gerar código incorreto. Esse comportamento permite construir funções Wasm extremamente grandes ou projetadas para consumir muitos identificadores e forçar uma confusão de tipos que poderia quebrar as garantias do sandbox. CVE-2026-115893 explora a instrução br_table de Wasm: em ARM64, Cranelift gerava um ramo “largo alcance” para a entrada por defeito do salto que só podia atingir um intervalo limitado (≈1 MiB). Quando uma tabela de saltos tinha demasiadas entradas (mais de ~256.000), o ramo excedia o alcance e apontava silenciosamente para uma direção errada, permitindo ao módulo controlado saltar para código arbitrário em processos com a configuração por defeito em ARM64. A correção muda a geração para que os índices fora de faixa passem pela própria tabela em vez de usar um ramo de longo alcance e adiciona um limiar de rejeição para tabelas excessivamente grandes (se nega br_table com mais de 65.520 destinos).

Quem corre maior risco — fatos e estimativas: confirmadamente, o risco real deriva da possibilidade de um terceiro suba ou entregar um módulo Wasm que o host compile com uma versão vulnerável de Wasmtime. Portanto, os serviços que aceitam e compilam código de usuários externos – por exemplo, plataformas de edge computing ou “serverless” que executam WebAssembly – são os mais expostos. Isto é coerente com exemplos públicos: fornecedores como o Fastly documentaram o uso de Wasmtime em plataformas que executam código de clientes, o que ilustra o modelo de ameaça, embora os avisos oficiais não listam serviços afetados ou reclamam incidências conhecidas. É uma estimativa razoável (mas não uma confirmação) que ambientes que não compilam módulos de terceiros ou que apenas executam módulos assinados/certificados têm risco muito menor.

Alcance das versões e suporte — fatos-chave para a mitigação: Wasmtime mantém linhas com suporte diferente: as LTS (multiplos de 12) recebem suporte por dois anos; outras linhas apenas dois meses. Os mantenedores indicaram que apenas as linhas 36, 48, 49 e 50 estavam suportadas no momento do aviso; muitos ramos antigos, incluindo a LTS 24.x cujo suporte terminou em 20 de agosto de 2026, não receberam correção. As versões de acordo com cada linha são: atualizar a 36.0.19, 48.0.7, 49.0.4 ou a Wasmtime 50.0.0 (esta última corrige ambos os erros). Importante: Wasmtime é geralmente incorporado como biblioteca: atualizar apenas a ferramenta de linha de comandos não mitiga dependências embebidas; cada produto que inclua Wasmtime deve ser recompilado ligando a versão segura.

Acções concretas e priorizadas que você deve tomar agora: 1) Inventariar usos: identifique all os binários, contentores e pacotes que incluem Wasmtime em seu ambiente e determine a linha de versão (por exemplo, 36.x, 48.x, 49.x, 50.x ou linhas não suportadas). 2) Actualizar e recompilar: para ambientes suportados, atualize as versões corrigidas acima indicadas; para produtos que embeben Wasmtime como livraria, reconstruia esses programas com a versão segura; para linhas não suportadas, migre a uma linha suportada e aplique o adesivo. 3) Analisar a exposição: se seu serviço compila módulos de usuários, trate esses pontos de entrada como de máxima prioridade para adesivo e implantação. 4) Detectar dependências: execute ferramentas como cargo-audit para detectar as entradas RUSTSEC (as IDs associadas figuram no RustSec); isto ajuda a encontrar o Wasmtime em cadeias de dependências. 5) Controlos compensatórios se não puder ser corrigido imediatamente: restrinja a possibilidade de terceiros suban ou compilem módulos (por exemplo, desactive a compilação JIT de módulos não verificados, implemente rejeição de cargas, exija assinatura de módulos ou isole a compilação dentro de sandboxes OS adicionais como contentores com políticas seccomp/SELinux). 6) Registrar e monitorar: habilite logs detalhados de execução e monitorize comportamentos atípicos (saltos incomuns, execução fora de memória atribuída) e vigile alertas públicos e entradas em bases como GitHub Advisory Database, RustSec e CISA.

O que ainda não está claro ou confirmado: Os avisos não detalham quais recursos concretos poderia obter um atacante após escapar do sandbox nem enumeram fornecedores afetados; também não especificam com precisão quando a equipe reconheceu o impacto em segurança para a primeira vulnerabilidade (a correção técnica — ampliar campos a 32 bits — foi introduzida previamente por motivos de capacidade). Também não existem dados públicos verificados de exploração em campanhas ativas ao fechar os avisos. Na ARM64, a segunda falha existe desde que Wasmtime suporta essa arquitetura (2020), mas não há evidência pública de abusos massivos.

Para consultar as correções e baixar as versões publicadas, consulte a página de lançamento do projeto: Wasmtime v50.0.0, verifique as entradas de segurança em RustSec: RUSTSEC-2026-0380 e RUSTSEC-2026-0379. Para contexto sobre a lista de vulnerabilidades exploradas e seu seguimento por infra-estruturas críticas, consulte o catálogo da CISA: CISA KEV catalog.

Em resumo: tente estas correcções como de alta prioridade se a sua infra-estrutura compila ou executa módulos Wasm de origem não confiável; adesivo e recompilar bibliotecas é a medida segura e direta. Se não for possível fazê-lo imediatamente, reduza a exposição restringindo a ingestão e compilação de módulos e aplique controlos adicionais ao nível do recipiente e autenticação de módulos até que a solução definitiva seja implementada.