Marimo bajo la vulnerabilidad crítica CVE-2026-39987 expone secretos en minutos

La comunidad de ciencia de datos y desarrollo en Python se ha despertado con una noticia inquietante: pocos horas después de que se hiciera pública una vulnerabilidad grave en Marimo —un entorno de notebooks reactivos de código abierto muy popular entre científicos de datos, investigadores y creadores de aplicaciones—, atacantes ya estaban aprovechando ese fallo para entrar y extraer secretos.

La vulnerabilidad, registrada como CVE-2026-39987, fue calificada por GitHub con una puntuación crítica (CVSS alta cercana a 9.3/10) y afecta a versiones de Marimo anteriores a la corrección. En esencia, un endpoint de WebSocket expuesto bajo la ruta /terminal/ws permitía acceder a una terminal interactiva sin que se verificaran credenciales, lo que abría la puerta a la ejecución remota de comandos con los mismos permisos que el proceso de Marimo.

Los desarrolladores del proyecto publicaron una advertencia y después lanzaron una versión corregida, la 0.23.0, para mitigar el problema. La advertencia también especificó que el riesgo era especialmente relevante para quienes despliegan Marimo en modo editable o lo exponen a redes compartidas usando la opción --host 0.0.0.0 en modo de edición.

Un informe técnico de la firma de seguridad en la nube Sysdig documenta cómo la explotación pasó de la teoría a la práctica en tiempo récord. Según su análisis, en las primeras 12 horas tras la publicación de los detalles, más de un centenar de direcciones IP realizaron escaneos en busca de instalaciones vulnerables, y en menos de 10 horas se observó la primera sesión de explotación que concretamente robó credenciales y secretos del sistema. El informe de Sysdig describe paso a paso cómo los atacantes validaron la falla, conectándose al endpoint vulnerable y ejecutando un pequeño script para comprobar la ejecución remota antes de desconectarse y regresar minutos después para una exploración manual más detallada (informe de Sysdig).

Lo que distingue a este ataque no fue una ola indiscriminada de scripts automáticos, sino la actuación de un operador que, según los investigadores, llevó a cabo una operación metódica y dirigida. En la sesión activa se ejecutaron comandos básicos de reconocimiento del entorno (como pwd, whoami y ls), búsqueda de archivos sensibles y, de forma muy rápida, lectura del fichero .env para extraer variables de entorno, claves de nube y secretos de aplicación. Todo ese acceso de credenciales se completó en menos de tres minutos, y la sesión recurrente del atacante sugiere un interés claro por información valiosa más que por instalación de malware a largo plazo.

La naturaleza del acceso facilita entender por qué el daño puede ser inmediato: obtener variables de entorno o llaves SSH desde un entorno de desarrollo puede permitir movimientos laterales, acceso a recursos en la nube o la exfiltración de datos de producción. Aunque en este caso no se detectó intento de persistencia ni despliegue de mineros o puertas traseras, la capacidad de tomar secretos en cuestión de minutos convierte la vulnerabilidad en una prioridad para cualquiera que tenga Marimo expuesto.

Si eres administrador o desarrollador que utiliza Marimo, las medidas a tomar son claras y urgentes. Primero, actualizar a la versión 0.23.0 debe ser la acción inmediata para restaurar las comprobaciones de autenticación en el servicio. Si la actualización no es viable de forma inmediata, una mitigación efectiva es bloquear o deshabilitar el endpoint /terminal/ws en el proxy o firewall, y evitar exponer el servicio a redes públicas. Además, conviene vigilar las conexiones WebSocket hacia esa ruta y rotar cualquier secreto que pudiera haber quedado expuesto (variables de entorno, claves de acceso a servicios en la nube, tokens de API, etc.).

La explicación técnica y la cronología del ataque son una lección sobre la ventana de exposición que existe entre la divulgación responsable y el parche efectivo: la información técnica, aunque imprescindible para que los equipos puedan parchear, también llega a manos de actores con la capacidad de explotar fallos en cuestión de horas. Por eso muchas organizaciones combinan parches rápidos con controles de red adicionales y procesos automatizados para detectar patrones de exploración y exfiltración.

Marimo no es un proyecto menor: su popularidad en GitHub —con decenas de miles de estrellas y diversos forks— implica que una buena cantidad de entornos de experimentación y prototipos pueden verse afectados si no se aplican las recomendaciones. Puedes revisar el repositorio oficial del proyecto y la advertencia de seguridad en su página de GitHub para más detalles técnicos sobre el parche y las condiciones que disparan el riesgo: repositorio de Marimo y la advisoria de seguridad publicada por los mantenedores.

En resumen, este incidente recuerda dos cosas que deberían ser obvias y que a menudo no lo son: las herramientas de desarrollo y los entornos de notebooks no son inocuos por defecto cuando están expuestos, y la velocidad de reacción ante una vulnerabilidad puede marcar la diferencia entre un parche exitoso y el compromiso de secretos sensibles. Si gestionas despliegues de Marimo, prioriza la actualización, revisa el acceso de red y asume que cualquier secreto expuesto debe ser rotado.

Para seguir el caso y profundizar en los detalles técnicos del ataque, las fuentes principales son la base de datos NVD para la entrada de la CVE (CVE-2026-39987), la advertencia y el parche en el repositorio de Marimo (release 0.23.0) y el análisis forense y cronológico publicado por Sysdig (informe de Sysdig), que ofrecen la información necesaria para comprender qué ocurrió y cómo protegerse.