Una vulnerabilidad crítica en el bloc de notas open source para análisis de datos Marimo ha evidenciado la rapidez con la que los atacantes reaccionan ante avisos públicos de seguridad. Según datos de Sysdig, la primera tentativa de explotación de CVE-2026-39987 se registró menos de 10 horas después de hacerse pública la descripción del fallo, sin que existiera aún un exploit de prueba (PoC) disponible.
Detalles técnicos de CVE-2026-39987 en Marimo y su impacto
La vulnerabilidad CVE-2026-39987, con una puntuación de 9,3 en la escala CVSS, afecta a todas las versiones de Marimo hasta e incluyendo la 0.20.4. El problema ha sido corregido en la versión 0.23.0, por lo que actualizar a este lanzamiento o superior es crítico para cualquier entorno que ejecute el software.
El origen del fallo reside en la ausencia de comprobación de autenticación en el endpoint WebSocket /terminal/ws. Mientras que otros endpoints WebSocket —como /ws— invocan correctamente la función de validación validate_auth(), el endpoint /terminal/ws solo verifica el modo de funcionamiento y la compatibilidad de la plataforma, omitiendo por completo la validación del usuario.
Este error de diseño permite que un atacante remoto no autenticado establezca una conexión WebSocket con el terminal y obtenga una PTY interactiva en el servidor. En la práctica, cualquier instancia de Marimo expuesta a internet y vulnerable concede al atacante un acceso remoto tipo shell sin necesidad de credenciales, lo que se traduce en ejecución remota de código (RCE) con un riesgo muy elevado.
Explotación en el honeypot de Sysdig: menos de 10 horas hasta el primer ataque
Para observar ataques en el mundo real, Sysdig desplegó una instancia vulnerable de Marimo como honeypot. La primera explotación registrada se produjo 9 horas y 41 minutos después del anuncio público de la vulnerabilidad, momento en el que aún no circulaba un PoC público.
El operador malicioso se conectó al endpoint WebSocket /terminal/ws, obtuvo acceso a la shell y comenzó una fase de reconocimiento manual: navegó por el sistema de archivos, revisó la estructura de directorios y localizó posibles datos sensibles. En pocos minutos intentó extraer el contenido del archivo .env, localizar claves SSH y leer otros ficheros potencialmente confidenciales.
Tras aproximadamente una hora, el atacante regresó al honeypot, volvió a conectarse al terminal y comprobó si otros actores habían accedido al sistema, además de revisar de nuevo el contenido del archivo .env. No se observaron descargas de mineros de criptomonedas, instalación de puertas traseras ni cargas especialmente ruidosas; toda la actividad se centró en la exfiltración de credenciales y secretos.
Sysdig documentó cuatro conexiones al terminal en un intervalo de 90 minutos, con pausas entre sesiones. Este patrón es típico de una operación manual en la que se avanza de forma sistemática por un listado de objetivos y se revisan de manera periódica los resultados de cada intrusión.
Ventana de exposición: la explotación de vulnerabilidades ya se mide en horas
El hecho de que el atacante pudiera desarrollar un exploit funcional únicamente a partir del aviso oficial, sin PoC disponible, refleja una tendencia clara: los actores de amenazas con capacidades técnicas solo necesitan una descripción mínima para construir y desplegar rápidamente herramientas de ataque.
Informes recientes de la industria de ciberseguridad señalan que el tiempo medio entre la divulgación pública de una vulnerabilidad crítica y su explotación generalizada se ha reducido de semanas o días a meras horas. En contraste, en muchas organizaciones los ciclos de pruebas, validación y despliegue de parches siguen midiendo en días, lo que genera una ventana de exposición considerable durante la cual los sistemas quedan desprotegidos.
Por qué incluso herramientas open source poco conocidas son objetivos atractivos
El caso de Marimo desmonta la idea de que los atacantes solo se interesan por plataformas masivas o muy populares. Cualquier aplicación accesible desde internet sobre la que se publique un aviso de seguridad crítico se convierte en un objetivo prioritario, con independencia de su cuota de mercado o notoriedad.
Herramientas como Marimo suelen utilizarse en laboratorios de datos, entornos de investigación y plataformas DevOps, donde conviven en un mismo servidor claves de acceso a la nube, tokens de CI/CD, contraseñas de bases de datos y otros secretos de alto valor. Comprometer un único servicio de este tipo puede proporcionar al atacante un punto de apoyo ideal para escalar privilegios y moverse lateralmente por la infraestructura.
Recomendaciones de ciberseguridad para Marimo y entornos DevOps
1. Actualización inmediata de Marimo. Todas las instancias deben actualizarse como mínimo a la versión 0.23.0. Es esencial comprobar que no sigan en uso contenedores antiguos ni imágenes vulnerables en entornos de prueba o auxiliares.
2. Restringir el acceso de Marimo a internet. Las instancias no deberían ser accesibles directamente desde la red pública salvo que exista una necesidad justificada. Es recomendable situar el servicio tras un reverse proxy, utilizar VPN, listas de IP permitidas y mecanismos de autenticación corporativa (SSO, OAuth, IdP empresariales).
3. Minimizar la superficie de ataque. Si la funcionalidad de terminal no se utiliza, debe deshabilitarse o limitarse exclusivamente a administradores. Los endpoints WebSocket con capacidades administrativas han de permanecer cerrados a redes externas y protegidos mediante controles adicionales.
4. Proteger secretos y credenciales. El incidente muestra que los archivos .env y las claves SSH son objetivos inmediatos. Las mejores prácticas recomiendan almacenar datos sensibles en gestores de secretos dedicados (como Vault o servicios KMS), reducir al mínimo las claves de larga duración y aplicar rotaciones periódicas automatizadas.
5. Monitorización y respuesta ante incidentes. Es aconsejable recopilar y correlacionar registros de conexiones WebSocket y actividad de terminales, así como alertar sobre comportamientos anómalos en shells dentro de entornos cloud y de contenedores. Ante cualquier indicio de compromiso, se debe revisar exhaustivamente la telemetría, revocar claves y tokens sospechosos y llevar a cabo un análisis forense del sistema afectado.
El caso de CVE-2026-39987 en Marimo demuestra que la distancia entre la publicación de una vulnerabilidad crítica y su explotación real puede ser inferior a diez horas. Resulta imprescindible reforzar los procesos de gestión ágil de vulnerabilidades, automatizar el despliegue de parches y revisar de forma continua qué servicios se exponen a internet. Cuanto menos tiempo disponga un atacante para actuar y menos secretos queden al alcance tras comprometer un solo servicio, menor será el impacto potencial sobre el negocio y la continuidad operativa.
