Los responsables del proyecto Wasmtime han alertado sobre dos vulnerabilidades críticas que podrían permitir a un módulo WebAssembly malicioso romper el aislamiento del sandbox diseñado para contenerlo. Para explotarlas, un atacante necesitaría primero que una compilación vulnerable de Wasmtime compilara un módulo bajo su control, y una de las fallas solo afecta a sistemas ARM64. Las versiones corregidas se publicaron el 19 y 20 de octubre, y los mantenedores no han informado de ataques en curso.
Wasmtime ejecuta código WebAssembly fuera de los navegadores web. Ambos errores se encuentran en Cranelift, el compilador que utiliza por defecto para convertir WebAssembly en código máquina. Los mantenedores de Wasmtime, agrupados en la Bytecode Alliance, otorgaron a cada fallo una puntuación de 9,9 sobre 10 en la escala CVSS en los avisos publicados el 19 de octubre.
- CVE-2026-115889 afecta a Wasmtime en todas las arquitecturas de procesador.
- CVE-2026-115893 afecta únicamente a ARM64, también denominada aarch64.
El sandbox tiene como objetivo mantener un módulo dentro de límites establecidos. Un módulo solo puede usar su propia memoria y las funciones del host que se le asignan, y su código solo puede saltar a ubicaciones verificadas. Dado que ambas fallas requieren un módulo controlado por el atacante, el riesgo es mayor para los servicios que compilan módulos escritos por terceros. Fastly, por ejemplo, afirma que su plataforma Compute ejecuta código de clientes mediante Wasmtime. Los avisos no identifican servicios afectados ni especifican a qué podría acceder un atacante tras escapar del sandbox. Ninguna de las dos fallas figuraba en el catálogo de vulnerabilidades explotadas conocidas (KEV) de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) a fecha del 26 de octubre.
Qué versiones están afectadas
Los dos fallos se corrigieron en momentos distintos, por lo que la exposición depende de la línea de versión y, en uno de los casos, de la arquitectura del procesador. Wasmtime mantiene las versiones de soporte a largo plazo (LTS), numeradas en múltiplos de 12, durante dos años; el resto de versiones recibe soporte durante dos meses. Las correcciones de seguridad están garantizadas para las versiones con soporte.
Solo las líneas 36, 48, 49 y 50 siguen recibiendo soporte. Todas las demás, incluida la línea LTS 24.x, cuyo soporte finalizó el 20 de agosto de 2026, no recibieron corrección. Los hosts ARM64 que se actualizaron a 36.0.7, 42.0.2 o 43.0.1 en abril para corregir una escapada de sandbox anterior en Cranelift para ARM64 siguen afectados por CVE-2026-115893.
Qué hacer
Actualice a la versión corregida de su línea: 36.0.19, 48.0.7 o 49.0.4. Wasmtime 50.0.0, publicada el 20 de octubre, corrige ambos fallos. Los hosts en una línea sin soporte deben migrar a una de estas versiones. Dado que Wasmtime puede integrarse en otros programas como biblioteca, actualizar la herramienta de línea de comandos no basta: cada programa que incluya Wasmtime debe recompilarse con una versión corregida.
Ninguno de los avisos incluye una solución alternativa. Hasta que se actualice un host, el riesgo proviene de cualquier módulo que un tercero pueda suministrar. Ambas fallas figuran en RustSec, la base de datos que utiliza la herramienta cargo-audit para revisar archivos Cargo.lock, como RUSTSEC-2026-0380 y RUSTSEC-2026-0379. A fecha del 26 de octubre, la base de datos de avisos de GitHub tenía una entrada revisada para CVE-2026-115889, pero ninguna para CVE-2026-115893. GitHub señala que solo las entradas revisadas generan alertas de Dependabot, por lo que los usuarios de Dependabot no deben esperar una alerta por la falla de ARM64. Spin, una herramienta de código abierto para crear aplicaciones WebAssembly serverless que funciona sobre Wasmtime, pasó a Wasmtime 50.0.0 en su versión 4.2.4 el 21 de octubre.
Cómo funcionan los dos fallos
CVE-2026-115889 deriva de cómo Cranelift almacenaba los números que utiliza para rastrear valores dentro de una función. Antes de la versión 43, empaquetaba esos números en campos de 24 bits y, en compilaciones de release, un número demasiado grande para su campo se desbordaba sin generar error. Cranelift podía entonces referirse al valor equivocado y producir código máquina incorrecto. Según el aviso, una función WebAssembly muy grande, o una diseñada para usar muchos valores, puede aprovechar esto para forzar una confusión de tipos y escapar del sandbox.
La línea principal de desarrollo de Wasmtime ya había eliminado el problema. Un cambio integrado el 18 de febrero amplió los campos a 32 bits y se distribuyó en Wasmtime 43.0.0 el 20 de marzo. Su descripción lo presentaba como una forma de compilar funciones más grandes y no mencionaba la seguridad. La línea LTS 36.x recibió el mismo cambio el 19 de octubre. El aviso no indica cuándo se reconoció el impacto de seguridad.
CVE-2026-115893 afecta a br_table, una instrucción de WebAssembly que salta a uno de varios puntos del código según un índice. Un índice fuera de la tabla se dirige a un destino predeterminado. En ARM64, Cranelift enviaba estos índices fuera de rango al destino predeterminado mediante una rama que solo puede alcanzar aproximadamente 1 MiB. Un br_table con más de unos 256.000 destinos hacía que la tabla de saltos fuera demasiado grande para ese alcance, por lo que la rama apuntaba silenciosamente a un lugar incorrecto.
Según el aviso, cualquier motor Wasmtime en ARM64 con la configuración predeterminada «puede ser forzado a saltar a código arbitrario mediante un módulo Wasm controlado por el usuario». El error ha estado presente desde que Wasmtime comenzó a soportar ARM64 en 2020. La corrección hace que los índices fuera de rango pasen por la propia tabla de saltos, de modo que no se necesita una rama larga. Las versiones corregidas también rechazan compilar un br_table con más de 65.520 destinos.
Deja una respuesta