Wasmtime y CVE-2026-115889: verifica el motor que llega a producción
Guía defensiva para revisar CVE-2026-115889 en Wasmtime, distinguir crate, CLI, API y bindings, y elegir una rama soportada sin ejecutar un exploit.
5 de noviembre de 2026 · Leopoldo Benavente Cadena · 6 min de lectura
Un sandbox de WebAssembly depende de más que las comprobaciones visibles en el código host. También depende de que el compilador que transforma el módulo genere referencias correctas. El advisory de Wasmtime describe un error de bit-packing en Cranelift que podía provocar una compilación incorrecta y, en determinadas condiciones, romper el aislamiento del sandbox.
El problema está identificado como CVE-2026-115889, GHSA-897f-g5gm-fmxm y RUSTSEC-2026-0380. Las fuentes lo califican como crítico, con CVSS 3.1 de 9.9. No hay evidencia en esas fuentes de explotación activa; la respuesta prudente es identificar el artefacto real, actualizar una rama soportada y validar el producto sin construir un módulo malicioso ni ejecutar una prueba de concepto.
Qué ocurrió en Cranelift
Antes de Wasmtime 43, el backend Cranelift empaquetaba índices de valores SSA en un espacio insuficiente. En una compilación release, el desbordamiento podía ser silencioso y producir referencias incorrectas en la representación intermedia. El advisory explica que una función Wasm muy grande o diseñada para usar muchos valores SSA podía forzar una miscompilación con efectos arbitrarios y escapar del sandbox.
Wasmtime 43 cambió Cranelift para usar un índice u32 completo y comprobar el límite. La corrección de la rama LTS 36 llegó en 36.0.19. Esto describe la causa y los parches del motor; no significa que toda aplicación Wasm sea vulnerable ni que la presencia de WebAssembly implique automáticamente el uso de Wasmtime o Cranelift.
Matriz exacta de versiones
| Versión de Wasmtime | Estado frente a este CVE | Decisión prudente |
|---|---|---|
Menor que 36.0.19 |
Afectada | Actualizar dentro de una rama soportada |
36.0.19 hasta antes de 37.0.0 |
Corregida para este CVE | Usar el patch LTS posterior disponible; al corte, 36.0.20 |
37.0.0 hasta antes de 43.0.0 |
Afectada | Migrar a una rama corregida y soportada |
43.0.0 o posterior |
No afectada por este error de bit-packing | 43.0.0 ya está fuera de soporte; elegir una estable soportada, 50.0.1 al corte |
La base de datos RustSec expresa la corrección como >=36.0.19,<37.0.0 o >=43.0.0. “Corregida para este CVE” no equivale a “sin otros avisos” ni a “con soporte vigente”. 36.0.19 es solo el mínimo corregido de la LTS 36; al permanecer en ella, prefiere 36.0.20. 43.0.0 cruza el umbral de corrección, pero ya está fuera de soporte; al corte, 50.0.1 es la estable soportada. La candidata 51.0.0-rc.1 no sustituye una release estable ni debe usarse en producción. Revisa siempre la rama vigente, los requisitos de tu producto, cambios de API y advisories publicados después.
La política de Wasmtime publica una nueva versión mayor cada mes. Las versiones múltiplo de 12 son LTS y reciben soporte durante 24 meses; las demás reciben soporte durante dos meses. Los errores de seguridad se retroportan a ramas soportadas y los patch releases mantienen compatibilidad de API y comportamiento dentro de la rama. 36.0.19 es el mínimo corregido para este CVE dentro de la LTS 36, no la recomendación operativa final: al corte, 36.0.20 es el patch posterior que conviene preferir si debes permanecer en esa LTS y recoge correcciones posteriores. 43.0.0 supera el umbral que corrige este CVE, pero su ciclo normal de soporte ya terminó; no la elijas solo por aparecer como versión corregida. Al corte, 50.0.1 figura como estable y soportada. 51.0.0-rc.1 es una candidata de pre-release sin garantías de soporte o estabilidad, por lo que no debe recomendarse para producción.
No busques solo el binario
Wasmtime puede llegar al producto por varias rutas:
| Artefacto | Qué comprobar |
|---|---|
Crate Rust wasmtime |
Cargo.lock, cargo tree y el commit/target de la build que crea el binario |
CLI wasmtime o wasmtime-cli |
El ejecutable dentro de la imagen o runner que lo ejecuta |
| API C | La biblioteca nativa y sus headers/artefactos que enlaza el producto |
| Binding | La versión del paquete y la versión nativa de Wasmtime que empaqueta o carga |
| Contenedor o plataforma de plugins | Digest de la imagen y dependencias dentro del entorno desplegado |
Una consulta wasmtime -V en el portátil solo describe esa CLI. No demuestra qué crate quedó resuelto en el lockfile, qué biblioteca usa un binding ni qué binario contiene la imagen. Un binding puede publicar su propio paquete y calendario; confirma su documentación y la dependencia nativa concreta en vez de inferir que sigue automáticamente la versión de la CLI.
Para una aplicación Rust, ejecuta las comprobaciones en el commit y entorno de build correctos:
cargo tree -i wasmtime
cargo tree -i cranelift-codegen
cargo metadata --format-version 1cargo tree ayuda a encontrar qué dependencia incorpora el crate. cargo metadata permite registrar el grafo que el gestor resolvió. Ninguno sustituye la inspección del artefacto final: un lockfile diferente, otro target o una imagen anterior puede haber llegado a producción.
Para la CLI, usa el mismo contenedor o máquina que vas a evaluar:
wasmtime -VGuarda la salida junto con el digest de la imagen. Para la API C o los bindings, registra el nombre y la versión del paquete, la biblioteca nativa, la arquitectura y el origen del artefacto. No ejecutes módulos desconocidos solo para comprobar la versión.
Actualizar y probar sin un exploit
Haz el cambio en una rama controlada. Regenera Cargo.lock únicamente mediante el gestor del proyecto, construye un artefacto nuevo y conserva el anterior para rollback. Si la aplicación consume Wasmtime desde una imagen, actualiza el Dockerfile o manifiesto, fija el nuevo digest y vuelve a escanear la imagen; no reemplaces una biblioteca a mano dentro de un contenedor ya desplegado.
La validación segura usa módulos Wasm propios y de confianza, con las rutas funcionales normales: carga, instanciación, llamadas permitidas, límites de recursos y errores esperados. Ejecuta las pruebas del host y del binding en staging, con los mismos flags y backend que usa producción. No construyas una función enorme para forzar el desbordamiento, no descargues una prueba de concepto desconocida y no pruebes contra un servicio ajeno.
Después de la build, repite cargo tree, cargo metadata o wasmtime -V dentro del artefacto correcto y conserva la relación entre versión, lockfile, imagen y resultado de pruebas. El objetivo es demostrar que el código que llega a la siguiente etapa contiene la rama corregida; una prueba funcional normal no demuestra ausencia de todas las vulnerabilidades.
El cierre debe incluir una revisión de otros advisories y una decisión de soporte. 36.0.19 es el mínimo histórico que corrige este CVE en la LTS 36; para una operación que deba seguir en esa rama, prefiere 36.0.20 al incorporar el patch posterior. 43.0.0 o posterior corrige este CVE en la matriz, pero 43.0.0 está fuera de soporte y no es una recomendación de producción. Al corte, 50.0.1 es la opción estable soportada; 51.0.0-rc.1 no ofrece garantías de pre-release y debe quedarse fuera de producción. En todos los casos, comprueba la compatibilidad de tus APIs, bindings y runtime.
Comentarios