Un operador humano explota una RCE en Marimo y alcanza un bastión SSH en ocho segundos

Un atacante humano explotó un fallo crítico de autenticación en la plataforma de notebooks de Python Marimo, extrajo credenciales de la nube, recuperó una clave SSH privada y accedió a un host bastión en ocho segundos.

Sysdig observó más de 850 comandos interactivos durante una intrusión de aproximadamente nueve horas. En lugar de desplegar un framework de explotación conocido o un agente de IA, el operador creó y depuró scripts personalizados de Python dentro del entorno comprometido.

El fallo de acceso inicial, CVE-2026-39987, afecta a las versiones de CoreWeave Marimo anteriores a la 0.23.0. Ya figura en el catálogo Known Exploited Vulnerabilities de la Cybersecurity and Infrastructure Security Agency de Estados Unidos, lo que confirma que la explotación va más allá de una prueba de concepto teórica.

Un WebSocket sin autenticación abrió una shell completa

Marimo es una aplicación reactiva de notebooks de Python. En las versiones vulnerables, su endpoint WebSocket /terminal/ws puede proporcionar a un usuario remoto sin autenticación una shell completa de pseudo-terminal.

El problema subyacente es la ausencia de autenticación, clasificada como CWE-306. El endpoint verifica el modo de funcionamiento de Marimo y si la plataforma admite la funcionalidad de terminal solicitada, pero no aplica el control de autenticación presente en otras rutas WebSocket, incluida /ws.

Como consecuencia, una instancia expuesta a Internet puede permitir que un atacante ejecute comandos arbitrarios del sistema operativo sin credenciales ni interacción del usuario.

El operador observado se conectó a /terminal/ws desde 172.236.12[.]17. La actividad continuó desde las 12:52 p. m. hasta las 9:50 p. m., aunque no se ha revelado la fecha del incidente.

NVD asigna a la vulnerabilidad una puntuación CVSS v3.1 de 9,8, con el siguiente vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Esta evaluación describe una vulnerabilidad accesible a través de la red, con baja complejidad de ataque, sin privilegios requeridos ni interacción del usuario, y con posibles efectos graves sobre la confidencialidad, la integridad y la disponibilidad. Otro informe asigna al fallo una puntuación de 9,3, pero la definición de versiones afectadas de NVD es más específica: las versiones de CoreWeave Marimo anteriores a la 0.23.0.

Marimo 0.23.0 incluye la corrección.

Del acceso al notebook al bastión en cuestión de segundos

El atacante no ejecutó de inmediato un payload perfeccionado. Durante la intrusión, el operador escribió, probó y corrigió código Python repetidamente, hasta reducir el flujo de trabajo a un único comando python3 ejecutado en segundo plano.

Ese comando automatizó un pivote en cinco etapas:

1. Leer las credenciales disponibles dentro del entorno Marimo comprometido.
2. Utilizar las credenciales de AWS obtenidas para consultar AWS Secrets Manager.
3. Recuperar una clave SSH privada almacenada.
4. Guardar la clave en el sistema de archivos local.
5. Autenticarse en un host bastión SSH.

La secuencia decisiva duró ocho segundos. A las 18:57:22, el atacante estableció una nueva conexión WebSocket. A las 18:57:26, una consulta devolvió la clave de AWS almacenada por la aplicación. La autenticación SSH contra el bastión tuvo lugar a las 18:57:30.

Este intervalo es importante desde el punto de vista operativo. Los equipos de defensa que dependan de revisiones manuales o de análisis por lotes lentos apenas tendrían oportunidad de interrumpir la transición después del primer evento WebSocket visible. Por tanto, la prevención, el aislamiento de credenciales y la contención automatizada son más fiables que esperar a que un analista reaccione durante el pivote.

El operador también experimentó con una configuración de listener de estilo asyncssh que implicaba un servidor privado virtual controlado por el atacante. En el historial de comandos no se identificó ningún toolkit ofensivo público reconocible.

Automatización rápida sin un agente de IA

La intrusión se asemeja a una actividad agéntica por su velocidad, pero las pruebas apuntan a que un humano dirigía la automatización personalizada.

Más de 850 comandos interactivos, junto con el desarrollo y la depuración visibles de scripts, indican que el operador refinaba activamente el ataque. Una vez que los pasos necesarios funcionaron, el atacante los combinó en un proceso compacto de Python capaz de completar a velocidad de máquina la cadena que iba desde las credenciales hasta SSH.

Sysdig también había observado operadores automatizados o agénticos dirigirse contra la misma vulnerabilidad. Esos operadores se toparon con una trampa defensiva que detuvo o alteró su flujo de trabajo; el atacante humano la evitó.

Este contraste pone de manifiesto una limitación de los controles diseñados en torno a una automatización predecible. Los agentes de IA y las herramientas estandarizadas pueden repetir secuencias reconocibles, confiar en respuestas engañosas o fallar cuando cambian las condiciones del entorno. Un humano cualificado puede inspeccionar el sistema, reconocer comportamientos anómalos y modificar la ruta de ejecución.

Esto no significa que los atacantes humanos sean intrínsecamente más rápidos que los sistemas autónomos. Demuestra que una persona puede preparar y lanzar una automatización después de comprender el objetivo, combinando criterio adaptativo con una ejecución prácticamente instantánea.

CISA ya había clasificado el fallo como explotado

CISA añadió CVE-2026-39987 a su catálogo Known Exploited Vulnerabilities el 23 de abril de 2026. La fecha límite de remediación para las agencias federales estadounidenses incluidas en el ámbito de aplicación era el 7 de mayo de 2026.

La medida exigida consiste en aplicar las mitigaciones del proveedor, seguir las directrices aplicables de la BOD 22-01 para servicios en la nube o dejar de utilizar el producto si no hay mitigaciones disponibles.

Su inclusión en KEV significa que las instalaciones vulnerables expuestas no deben considerarse un riesgo meramente potencial. La explotación está documentada, y el incidente recién comunicado demuestra una ruta que va desde el compromiso de un notebook hasta los secretos confidenciales de la nube y la infraestructura SSH interna.

La información disponible no identifica ninguna otra vulnerabilidad reciente de Marimo en el catálogo KEV. Por tanto, la prioridad inmediata es CVE-2026-39987 y cualquier credencial expuesta a través de instancias de notebooks vulnerables.

Qué deben investigar los operadores de Marimo

Los administradores deben actualizar todas las implementaciones afectadas de Marimo a la versión 0.23.0 o posterior. También deben restringir el acceso a /terminal/ws en la capa de red o del proxy inverso, especialmente cuando los sistemas de notebooks no necesiten ser accesibles públicamente.

Aplicar el parche no es suficiente si ya se ha producido una explotación. Los equipos de respuesta ante incidentes deben asumir que las credenciales accesibles para el proceso de Marimo podrían haber sido recopiladas.

Entre las medidas recomendadas se incluyen:

• Rotar las credenciales de AWS almacenadas en la instancia afectada o expuestas a ella.
• Revisar el acceso a AWS Secrets Manager para detectar recuperaciones inesperadas desde cargas de trabajo de notebooks.
• Revocar y sustituir las claves SSH privadas a las que pudiera acceder el entorno comprometido.
• Buscar claves privadas escritas inesperadamente en el almacenamiento local.
• Examinar los logs del bastión para detectar accesos SSH inmediatamente posteriores a sesiones WebSocket de Marimo.
• Investigar las conexiones relacionadas con 172.236.12[.]17.
• Buscar procesos de Python ejecutados en segundo plano y listeners de estilo asyncssh desconocidos.
• Correlacionar las conexiones a /terminal/ws con llamadas a las API de la nube, recuperaciones de secretos, escrituras en el sistema de archivos y autenticaciones SSH.

Los equipos también deben determinar si los roles de ejecución de los notebooks tienen permiso para recuperar claves SSH de producción. Eliminar ese acceso puede impedir que el compromiso de un notebook se convierta en un pivote de credenciales que afecte a toda la infraestructura.

Campañas independientes apuntan a Redis y a cámaras Dahua

El informe también describió dos operaciones independientes que no se atribuyeron al atacante de Marimo.

Una campaña de cryptomining comprometió 3.562 servidores Redis después de buscar servicios expuestos en el puerto TCP 6379. La operación utilizó el comando SLAVEOF de Redis para transferir contenido controlado por el atacante e instalar el minero XMRig.

Las víctimas utilizaban versiones comprendidas entre Redis 2.8.17 y 7.2.0, e incluían entornos Linux obsoletos y actuales. La exposición común parece haber sido la ausencia de autenticación, no una vulnerabilidad exclusiva de una versión concreta de Redis.

Los equipos de defensa deben eliminar Redis de la exposición directa a Internet, exigir autenticación, revisar la configuración de replicación y buscar actividad SLAVEOF inesperada, modificaciones de archivos append-only, claves SSH y procesos de XMRig.

Otra campaña, Operation CameraSwarm, comprometió más de 14.000 cámaras IP Dahua mediante ataques de fuerza bruta, retransmisión entre pares y los fallos de bypass de autenticación CVE-2021-33044 y CVE-2021-33045.

Ambas vulnerabilidades de Dahua tienen una puntuación CVSS de 9,8 y figuran en el catálogo KEV de CISA desde el 21 de agosto de 2024. La fecha límite de remediación federal era el 11 de septiembre de 2024. Las organizaciones deben aplicar las mitigaciones de Dahua o dejar de utilizar los dispositivos afectados cuando no haya ninguna mitigación disponible.