Wasmtime corrige dos fallas críticas que permiten escapar del sandbox de WebAssembly

0 0 votos

Valora la Publicación

Wasmtime, el motor de la Bytecode Alliance para ejecutar WebAssembly fuera del navegador, corrigió dos vulnerabilidades críticas (CVSS 9.9 según sus avisos) en su compilador Cranelift que permiten que un módulo malicioso escape del sandbox y ejecute código en el servidor. Las versiones corregidas son 36.0.19, 48.0.7 y 49.0.4, y no hay mitigación por configuración: la única salida es actualizar y recompilar.

Los avisos se publicaron el 19 de octubre de 2026 y volvieron a circular el 26 de octubre con la cobertura de The Hacker News. Los mantenedores no reportan ataques y ninguna de las dos fallas figura en el catálogo de vulnerabilidades explotadas de CISA.

Qué es Wasmtime y por qué importa el sandbox

WebAssembly (Wasm) es un formato de código compilado que nació para el navegador y hoy se usa también en servidores. Su atractivo es el aislamiento: un módulo Wasm corre dentro de un sandbox, un entorno cerrado que no le deja tocar la memoria ni los archivos del sistema que lo aloja.

Wasmtime es el motor de la Bytecode Alliance que ejecuta esos módulos. Se integra como librería de Rust dentro de otros programas, y por eso aparece en plataformas que corren código de terceros:

Sistemas de plugins o extensiones que ejecutan código que escribió un cliente.
Funciones serverless y de edge que reciben módulos de muchos usuarios en el mismo servidor.
Herramientas internas que usan Wasm para aislar lógica de negocio o reglas configurables.

En todos esos casos el sandbox es la barrera de seguridad. Si un módulo puede salir de él, puede leer datos de otros clientes o tomar el control del proceso que lo ejecuta.

Las dos fallas

Las dos están en Cranelift, el compilador que Wasmtime usa por defecto para traducir el módulo Wasm a código de máquina antes de ejecutarlo. Si el compilador genera código incorrecto, las verificaciones del sandbox pueden quedar sin efecto.

CVE-2026-115889 (cualquier arquitectura): Cranelift empaqueta los índices internos de los valores de cada función en pocos bits. En compilaciones de producción, una función muy grande o armada a propósito desborda ese espacio sin aviso y el compilador termina usando un valor por otro. Eso produce código mal compilado, confusión de tipos y posible escape del sandbox. Afecta a versiones anteriores a 36.0.19 y de la 37.0.0 a la 42.x; desde la 43.0.0 está corregida (GHSA-897f-g5gm-fmxm).
CVE-2026-115893 (solo ARM64): una instrucción br_table (un salto a uno de muchos destinos posibles, como un switch) con más de unos 256.000 destinos compila a un salto que cae en el lugar equivocado. Un módulo controlado por el atacante puede redirigir la ejecución a código arbitrario. Afecta la configuración por defecto en servidores ARM64 y está presente desde que Cranelift soporta esa arquitectura, en 2020 (GHSA-mghf-wjfp-p5xm).

Para explotar cualquiera de las dos, el atacante necesita que el servidor compile un módulo Wasm que él controla. Por eso el riesgo real está en las plataformas que aceptan módulos de terceros, no en las que solo ejecutan código propio y revisado.

Qué versiones instalar

Según los avisos y las notas de versión del proyecto, las correcciones salieron el 19 de octubre:

Rama 36 (soporte extendido): 36.0.19, que corrige las dos.
Rama 48: 48.0.7.
Rama 49: 49.0.4.
De la 37 a la 47: no reciben parche; hay que pasar a una de las ramas anteriores o a la 50.0.0, publicada el 20 de octubre.

Un detalle que suele pasarse por alto: los servidores ARM64 que ya se habían actualizado en abril a 36.0.7, 42.0.2 o 43.0.1, por un escape anterior (CVE-2026-34971), siguen expuestos a esta nueva falla. Aquel parche no cubre el problema de br_table.

Qué tienen que hacer los equipos

Como Wasmtime se integra como librería, actualizar la herramienta de línea de comandos no alcanza: cada programa que la incluye tiene que recompilarse con la versión corregida y volver a desplegarse.

Buscar el crate wasmtime en los Cargo.lock de todos los repositorios, también como dependencia indirecta, y anotar la versión.
Priorizar los servicios que compilan módulos que suben clientes o usuarios externos, y los que corren en ARM64 (por ejemplo, instancias Graviton o Ampere).
Actualizar a 36.0.19, 48.0.7, 49.0.4 o 50.0.0, recompilar, desplegar y verificar la versión en producción.
Preguntar a los proveedores de plataformas que ejecutan Wasm (serverless, edge, plugins) si ya aplicaron la actualización.
No depender solo de las alertas automáticas de dependencias: revisar la versión a mano mientras las bases de avisos terminan de cargar las dos fallas.

Quienes usen la rama 24.x de soporte extendido están en otra situación: perdió soporte el 20 de agosto de 2026 y no recibe esta corrección, así que la única opción es migrar a una rama vigente.

¿Saben qué versión de Wasmtime corre en sus servicios?

WebAssembly suele entrar a una arquitectura como una dependencia más, y por eso es fácil perderle el rastro. ¿Ya revisaron sus Cargo.lock? Los leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →