Wasmtime corrige dos fallos graves en Cranelift (CVE-2026-115889, CVE-2026-115893)

En las últimas semanas se corrigieron dos fallos graves en Wasmtime, el entorno de ejecución de WebAssembly que se integra en programas fuera del navegador. Los mantenedores calificaron cada vulnerabilidad con 9.9/10 en la escala CVSS y publicaron parches entre el 19 y el 20 de octubre. Los errores permiten, en determinadas condiciones, que un módulo WebAssembly malicioso escape del sandbox que debería limitarlo y ejecute código fuera de su área autorizada. Según las notas oficiales, no hay reportes públicos de explotación activa hasta la fecha de corte indicada en los avisos.

Qué está confirmado: las dos fallas son implementacionales en Cranelift, el compilador por defecto que Wasmtime usa para convertir Wasm en código máquina. Están registradas como CVE-2026-115889 (afecta a todas las arquitecturas) y CVE-2026-115893 (afecta solo a ARM64/aarch64). Los mantenedores publicaron versiones corregidas (por ejemplo, Wasmtime 50.0.0 y parches puntuales en las líneas soportadas) que eliminan las condiciones vulnerables. Además, ambas entradas figuran en la base de vulnerabilidades RustSec bajo los identificadores mencionados, y el catálogo de vulnerabilidades explotadas conocido por CISA no incluía estas CVE al 26 de octubre.

Cómo funcionan técnicamente los fallos (resumen técnico verificable): CVE-2026-115889 proviene de cómo Cranelift codificaba internamente números usados para identificar valores dentro de una función: originalmente esos identificadores se ajustaban en campos de 24 bits y, en compilaciones de lanzamiento, un identificador que excediera ese espacio desbordaba sin detección, lo que podía hacer que el compilador remitiera al valor equivocado y generara código incorrecto. Ese comportamiento permite construir funciones Wasm extremadamente grandes o diseñadas para consumir muchos identificadores y forzar una confusión de tipos que podría romper las garantías del sandbox. CVE-2026-115893 explota la instrucción br_table de Wasm: en ARM64, Cranelift generaba una rama “largo alcance” hacia la entrada por defecto del salto que solo podía alcanzar un rango limitado (≈1 MiB). Cuando una tabla de saltos tenía demasiadas entradas (más de ~256.000), la rama excedía el alcance y apuntaba silenciosamente a una dirección equivocada, permitiendo al módulo controlado saltar a código arbitrario en procesos con la configuración por defecto en ARM64. La corrección cambia la generación para que los índices fuera de rango se pasen por la propia tabla en lugar de usar una rama de largo alcance y añade un umbral de rechazo para tablas excesivamente grandes (se niegan br_table con más de 65.520 destinos).

Quién corre mayor riesgo — hechos y estimaciones: confirmadamente, el riesgo real deriva de la posibilidad de que un tercero suba o entregue un módulo Wasm que el host compile con una versión vulnerable de Wasmtime. Por tanto, los servicios que aceptan y compilan código de usuarios externos —por ejemplo, plataformas de edge computing o “serverless” que ejecutan WebAssembly— son los más expuestos. Esto es coherente con ejemplos públicos: proveedores como Fastly han documentado el uso de Wasmtime en plataformas que ejecutan código de clientes, lo que ilustra el modelo de amenaza aunque los avisos oficiales no listan servicios afectados ni reclaman incidencias conocidas. Es una estimación razonable (pero no una confirmación) que entornos que no compilan módulos de terceros o que solo ejecutan módulos firmados/certificados tienen riesgo mucho menor.

Alcance de las versiones y soporte — hechos clave para la mitigación: Wasmtime mantiene líneas con soporte distinto: las LTS (multiplos de 12) reciben soporte por dos años; otras líneas solo dos meses. Los mantenedores indicaron que solo las líneas 36, 48, 49 y 50 estaban soportadas en el momento del aviso; muchas ramas antiguas, incluida la LTS 24.x cuyo soporte terminó el 20 de agosto de 2026, no recibieron corrección. Las versiones con arreglo para cada línea son: actualizar a 36.0.19, 48.0.7, 49.0.4 o a Wasmtime 50.0.0 (esta última corrige ambos fallos). Importante: Wasmtime suele incrustarse como biblioteca: actualizar únicamente la herramienta de línea de comandos no mitiga dependencias embebidas; cada producto que incluya Wasmtime debe recompilarse vinculando la versión segura.

Acciones concretas y priorizadas que debería tomar usted ahora: 1) Inventariar usos: identifique all los binarios, contenedores y paquetes que incluyen Wasmtime en su entorno y determine la línea de versión (p. ej., 36.x, 48.x, 49.x, 50.x o líneas no soportadas). 2) Actualizar y recompilar: para entornos soportados, actualice a las versiones corregidas indicadas arriba; para productos que embeben Wasmtime como librería, reconstruya esos programas con la versión segura; para líneas no soportadas, migre a una línea soportada y aplique el parche. 3) Analizar la exposición: si su servicio compila módulos de usuarios, trate esos puntos de entrada como de máxima prioridad para parcheo y despliegue. 4) Detectar dependencias: ejecute herramientas como cargo-audit para detectar las entradas RUSTSEC (las IDs asociadas figuran en RustSec); esto ayuda a encontrar Wasmtime afectado en cadenas de dependencias. 5) Controles compensatorios si no puede parchear de inmediato: restrinja la posibilidad de que terceros suban o compilen módulos (por ejemplo, desactive la compilación JIT de módulos no verificados, implemente rechazo de cargas, exija firma de módulos o aísle la compilación dentro de sandboxes OS adicionales como contenedores con políticas seccomp/SELinux). 6) Registrar y monitorizar: habilite logs detallados de ejecución y monitorice comportamientos atípicos (saltos inusuales, ejecución fuera de memoria asignada) y vigile alertas públicas y entradas en bases como GitHub Advisory Database, RustSec y CISA.

Lo que sigue sin estar claro o confirmado: los avisos no detallan qué recursos concretos podría obtener un atacante tras escapar del sandbox ni enumeran proveedores afectados; tampoco especifican con precisión cuándo el equipo reconoció el impacto en seguridad para la primera vulnerabilidad (la corrección técnica —ampliar campos a 32 bits— se introdujo previamente por motivos de capacidad). Tampoco hay datos públicos verificados de explotación en campañas activas al cierre de los avisos. En ARM64, el segundo fallo existe desde que Wasmtime soporta esa arquitectura (2020), pero no hay evidencia pública de abusos masivos de ello.

Para consultar las correcciones y descargar las versiones publicadas consulte la página de lanzamientos del proyecto: Wasmtime v50.0.0, y verifique las entradas de seguridad en RustSec: RUSTSEC-2026-0380 y RUSTSEC-2026-0379. Para contexto sobre la lista de vulnerabilidades explotadas y su seguimiento por infraestructuras críticas, consulte el catálogo de CISA: CISA KEV catalog.

En resumen: trate estas correcciones como de alta prioridad si su infraestructura compila o ejecuta módulos Wasm de origen no confiable; parchear y recompilar bibliotecas es la medida segura y directa. Si no puede hacerlo inmediatamente, reduzca la exposición restringiendo la ingesta y compilación de módulos y aplique controles adicionales a nivel de contenedor y autenticación de módulos hasta que se despliegue la solución definitiva.