Se corrigen escapes críticos de la sandbox de Wasmtime en las últimas versiones

Los mantenedores del tiempo de ejecución WebAssembly Wasmtime publicaron parches de seguridad urgentes los días 19 y 20 de octubre de 2026 para abordar dos vulnerabilidades críticas. Estos fallos, calificados con una puntuación de 9,9 sobre 10 en la escala CVSS, podrían permitir que un módulo malicioso escape de su sandbox y ejecute código arbitrario en el sistema anfitrión.

Qué ocurrió

La Bytecode Alliance, que mantiene Wasmtime, identificó dos errores distintos en Cranelift, el compilador predeterminado utilizado para traducir WebAssembly a código máquina. La primera vulnerabilidad, registrada como CVE-2026-115889, afecta a las instalaciones de Wasmtime en todas las arquitecturas de procesador. La segunda, CVE-2026-115893, es específica de los sistemas ARM64 (aarch64). Ambos problemas permiten un escape de la sandbox si un atacante puede suministrar un módulo WebAssembly manipulado a un tiempo de ejecución vulnerable.

El riesgo es más agudo para las plataformas que compilan y ejecutan código proporcionado por el usuario, como los entornos de computación sin servidor. Por ejemplo, servicios como la plataforma Compute de Fastly dependen de Wasmtime para aislar el código de los clientes. Aunque los avisos no nombran víctimas específicas ni detallan el acceso posterior a la explotación, el potencial de compromiso total del host es grave. Hasta el 26 de octubre, no se han reportado exploits activos, y ninguno de los fallos aparece en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA.

El estado de soporte juega un papel importante en la exposición. Solo las líneas de versión 36, 48, 49 y 50 reciben actualmente actualizaciones de seguridad. Las líneas anteriores, incluida la rama LTS 24.x que finalizó su soporte el 20 de agosto de 2026, no recibirán correcciones. Los usuarios en versiones no compatibles deben actualizar a una línea compatible para mitigar estos riesgos.

Cómo funciona

CVE-2026-115889 proviene de un desbordamiento de entero en la forma en que Cranelift rastrea los valores dentro de una función. En versiones anteriores a la 43.0.0, el compilador almacenaba estos números de seguimiento en campos de 24 bits. Si una función era lo suficientemente grande o compleja como para superar este límite, el valor se desbordaba silenciosamente en las compilaciones de lanzamiento. Esto hacía que Cranelift hiciera referencia a valores incorrectos, lo que provocaba confusión de tipos y generaba código máquina que violaba las restricciones de la sandbox. La solución amplía estos campos a 32 bits, un cambio fusionado originalmente en febrero por razones de rendimiento pero retroportado a la línea LTS 36.x el 19 de octubre por motivos de seguridad.

El fallo específico de ARM64, CVE-2026-115893, involucra la instrucción br_table, que maneja bifurcaciones múltiples. Cuando un índice cae fuera del rango de la tabla, el tiempo de ejecución salta a un destino predeterminado. En ARM64, Cranelift implementó esto utilizando una instrucción de bifurcación con un alcance limitado de aproximadamente 1 MiB. Si una br_table contenía más de unos 256.000 destinos, la tabla de saltos superaba este rango, haciendo que la bifurcación apuntara a una ubicación de memoria no intencionada. Esto permitía que un módulo manipulado redirigiera la ejecución a código arbitrario. El parche modifica el flujo de control para enrutar los índices fuera de rango a través de la propia tabla de saltos y limita el tamaño de br_table a 65.520 destinos.

Detalles clave

• CVE-2026-115889 afecta a todas las arquitecturas; CVE-2026-115893 afecta solo a los sistemas ARM64.
• Ambas vulnerabilidades tienen una puntuación CVSS de 9,9, lo que indica severidad crítica.
• Las versiones corregidas incluyen 36.0.19, 48.0.7, 49.0.4 y 50.0.0.
• La línea LTS 24.x no tiene soporte y no recibió parche; los usuarios deben migrar.
• Dependabot podría no alertar sobre el fallo de ARM64 ya que GitHub carece de una entrada revisada para él.
• La versión 4.2.4 del framework Spin se actualizó a Wasmtime 50.0.0 el 21 de octubre.

Por qué importa

Para los ingenieros que construyen plataformas que ejecutan WebAssembly no confiable, estos bugs representan un fallo fundamental en el aislamiento. La sandboxing es el mecanismo de defensa principal en dichas arquitecturas. Si un módulo puede escapar, obtiene los privilegios del proceso anfitrión, lo que potencialmente permite la exfiltración de datos, movimiento lateral o interrupción del servicio. El hecho de que un bug existiera desde 2020 destaca la dificultad de auditar la lógica de compiladores de bajo nivel, especialmente en casos extremos específicos de arquitectura.

Además, la dependencia de herramientas automatizadas como Dependabot puede proporcionar una falsa sensación de seguridad. Dado que GitHub requiere entradas revisadas para activar alertas, y el fallo de ARM64 carecía de una a finales de octubre, algunos equipos podrían seguir desconocedores de su exposición. Esto subraya la necesidad de una verificación manual de los árboles de dependencias frente a los avisos oficiales de los proveedores, particularmente para componentes de infraestructura crítica como los tiempos de ejecución.

Qué puedes hacer

• Identifica tu versión actual de Wasmtime y comprueba si se encuentra dentro de los rangos afectados listados en el aviso.
• Actualiza a 36.0.19, 48.0.7, 49.0.4 o 50.0.0 dependiendo de tu línea de versión.
• Si usas Wasmtime como librería, recompila tu aplicación con la versión parcheada; actualizar la herramienta CLI es insuficiente.
• Migra lejos de las líneas de versión sin soporte como la 24.x, ya que no recibirán futuras correcciones de seguridad.
• Ejecuta cargo-audit para comprobar RUSTSEC-2026-0380 y RUSTSEC-2026-0379 en tus archivos de bloqueo de dependencias.
• Monitoriza las actualizaciones de frameworks downstream como Spin si no gestionas Wasmtime directamente.