Falhas no Wasmtime abrem brecha grave para ataque em WebAssembly

Segurança

Vulnerabilidades críticas no Wasmtime expõem módulos WebAssembly a ataques, exigindo atualizações urgentes para proteção.

Leia também: CISA manda corrigir falhas críticas em Collabora e Arista

Duas falhas críticas no Wasmtime, runtime usado para executar código WebAssembly fora do navegador, permitem que módulos maliciosos escapem do sandbox e executem código arbitrário no sistema hospedeiro. As vulnerabilidades estão no compilador Cranelift, padrão do projeto mantido pela Bytecode Alliance, e uma delas atinge apenas sistemas ARM64, afetando desde servidores em nuvem até plataformas serverless como as que rodam código de clientes.

Falhas têm nota 9,9/10 e afetam quem roda código de terceiros

Os mantenedores do Wasmtime classificam as duas vulnerabilidades com pontuação de 9,9 em 10 na escala CVSS. Elas permitem que um módulo WebAssembly controlado por um atacante quebre o isolamento da sandbox, acesse áreas de memória fora dos limites previstos e, na prática, execute código fora das regras impostas pelo runtime.

O risco é maior para serviços que compilam e rodam módulos fornecidos por terceiros, como plataformas serverless, soluções de edge computing e ambientes de nuvem que expõem Wasmtime para clientes. Nesses cenários, basta que o atacante consiga submeter um módulo WebAssembly para compilação em uma instância vulnerável.

“Ambos os bugs foram avaliados com 9.9 de 10 na escala CVSS”, afirmam os mantenedores do Wasmtime na Bytecode Alliance nos avisos de segurança publicados com as correções.

Como funcionam as vulnerabilidades do Cranelift

A primeira falha, catalogada como CVE-2026-115889, nasce da forma como o Cranelift armazenava internamente números usados para rastrear valores dentro de uma função. Em versões antigas, esses identificadores eram guardados em campos de 24 bits, o que permitia um estouro silencioso quando o número ultrapassava o limite, especialmente em funções muito grandes ou construídas para usar uma quantidade extrema de valores.

Quando o overflow acontecia, o compilador passava a referenciar o valor errado, gerando código de máquina incorreto. Essa “confusão de tipos” abre caminho para que um módulo WebAssembly malicioso force o escape do sandbox. Segundo os mantenedores, “o problema foi removido na linha principal de desenvolvimento com uma mudança em fevereiro que aumentou os campos para 32 bits”, mudança que depois foi levada também para linhas LTS ainda suportadas.

A segunda falha, CVE-2026-115893, é exclusiva de sistemas ARM64 e envolve a instrução br_table do WebAssembly, que realiza saltos para diferentes trechos de código a partir de um índice. Em ARM64, o Cranelift tratava índices fora da faixa usando um desvio (branch) limitado a um alcance de cerca de 1 MiB.

Em tabelas de salto muito grandes — acima de aproximadamente 256 mil alvos — a estrutura gerada ficava maior que esse alcance, e o branch passava a apontar silenciosamente para endereços errados, permitindo que o módulo desviasse a execução para instruções arbitrárias. O aviso de segurança é direto: “Qualquer engine Wasmtime em ARM64 com configurações padrão pode ser forçada a saltar para código arbitrário por um módulo Wasm controlado pelo usuário”.

Para corrigir o problema, as versões novas passam a encaminhar índices fora da faixa pelo próprio jump table, eliminando o branch longo, e impõem um limite de 65.520 alvos para br_table.

Entenda o contexto

O Wasmtime é um runtime que permite rodar módulos WebAssembly em servidores, ferramentas de linha de comando e outros aplicativos, fora do navegador. Ele é amplamente adotado em plataformas que executam código de terceiros em ambiente isolado, justamente pela promessa de segurança e portabilidade.

Nesse modelo, o sandbox do WebAssembly garante que o módulo só use sua própria memória e as funções que o hospedeiro expõe, além de restringir os saltos de execução a endereços validados. Uma falha no compilador que gera o código de máquina — como o Cranelift — quebra essa premissa de isolamento.

Por isso, mesmo sem relatos de ataques em andamento e sem registro das falhas no catálogo de Vulnerabilidades Conhecidas e Exploradas de órgãos de cibersegurança internacionais, o caso é tratado como prioridade na comunidade de segurança e entre provedores de serviços que dependem do Wasmtime.

Quais versões do Wasmtime foram corrigidas?

As correções para as falhas foram publicadas em outubro e abrangem as principais linhas ainda suportadas do Wasmtime. “As versões corrigidas foram lançadas em 19 e 20 de outubro para as linhas suportadas”, informa o comunicado oficial do projeto.

Estão protegidas as versões 36.0.19, 48.0.7, 49.0.4 e 50.0.0. Todas as demais linhas que já saíram da janela de suporte — incluindo a antiga 24.x LTS, cujo ciclo de vida se encerrou em agosto — não receberam patches. Nesse caso, quem ainda roda versões antigas precisa migrar diretamente para uma dessas edições corrigidas.

O modelo de suporte do Wasmtime prevê que versões LTS, identificadas por números múltiplos de 12, recebam atualizações por dois anos. As versões intermediárias têm janela muito mais curta, de cerca de dois meses, o que explica por que tantos lançamentos deixaram de ser contemplados com correções.

O que os usuários do Wasmtime precisam fazer?

A orientação dos mantenedores é de atualização imediata. “Não há soluções alternativas listadas; o risco vem de qualquer módulo que um agente externo possa fornecer”, avisam os responsáveis pelo projeto.

Quem usa o Wasmtime apenas como ferramenta de linha de comando precisa conferir se não há bibliotecas internas ou serviços próprios incorporando o runtime como dependência. Nesses casos, não basta atualizar o binário instalado na máquina: é necessário recompilar cada programa que integra o Wasmtime, agora apontando para uma das versões corrigidas.

Ferramentas populares que dependem do Wasmtime, como plataformas para construção de apps serverless em WebAssembly, já começaram a se mover e anunciaram atualizações internas para as novas versões do runtime.

Impacto em ARM64 e na nuvem

A falha específica em ARM64 preocupa especialmente provedores que apostaram nessa arquitetura em data centers e serviços de nuvem, dada a adoção crescente de servidores com esses processadores por motivos de eficiência energética e custo.

Nesses ambientes, um cliente mal-intencionado que tenha acesso a um serviço serverless ou a uma plataforma edge baseada em Wasmtime poderia explorar a vulnerabilidade da instrução br_table para escapar do sandbox e alcançar recursos do hospedeiro. A depender da configuração, isso pode significar acesso a segredos, dados de outros clientes ou mesmo tomada de controle do processo que roda o runtime.

Embora não haja, até o momento, relatos públicos de exploração das falhas, a ausência de mecanismos de mitigação prática antes da atualização — como flags de compilação ou filtros de módulos — faz com que a janela de exposição seja tão longa quanto o tempo que cada administrador levar para atualizar seus ambientes.

Monitoramento e próximos passos

As duas vulnerabilidades já aparecem no banco de dados RustSec, usado por ferramentas como o cargo-audit para inspecionar dependências em projetos Rust, o que deve facilitar a identificação de versões vulneráveis em cadeias de software. No GitHub, a entrada para a falha geral de Cranelift já foi revisada e pode acionar alertas automáticos para alguns projetos, enquanto o alerta para o bug específico de ARM64 ainda não está completo.

Na prática, equipes de segurança e times de desenvolvimento que utilizam Wasmtime em produtos próprios precisam mapear onde o runtime está embutido, atualizar para as versões 36.0.19, 48.0.7, 49.0.4 ou 50.0.0 e acompanhar os canais oficiais do projeto em busca de eventuais novos detalhes técnicos ou exploração em ambiente real.