Un atacante humano explota un RCE de Marimo y llega a un bastión SSH en ocho segundos
Sysdig documenta una cadena completa contra CVE-2026-39987 sin ningún agente de IA de por medio, mientras Hunt.io cifra en 3.562 los servidores Redis usados para criptominería.
Un operador humano pasó de un notebook Marimo vulnerable a un bastión SSH en ocho segundos, sin ningún agente de IA en el proceso. Lo cuenta Sysdig en su análisis de CVE-2026-39987, un RCE preautenticado con CVSS 9,3 que afecta a todas las versiones de Marimo y que ya estaba siendo explotado horas después de su divulgación pública.
La cadena es corta y muy directa. El atacante entró por el endpoint /terminal/ws que expone Marimo, se hizo con un shell interactivo y desde ahí llamó a AWS Secrets Manager con las credenciales que había cosechado en la instancia comprometida. Con la clave privada recuperada, se autenticó en el bastión. Los tiempos que da la firma de seguridad: a las 18:57:22 una conexión WebSocket nueva; cuatro segundos después, la consulta a Secrets Manager devolviendo la clave de AWS; a las 18:57:30, autenticación SSH observada en el bastión.
"Ocho segundos es la velocidad que esperamos ver en ataques asistidos por IA", dice el equipo de investigación de Sysdig. "Este operador llegó ahí solo con habilidad, y de paso se saltó una trampa en la que cayeron todos los agentes de amenaza agénticos que hemos perfilado contra este mismo CVE".
Nueve horas dentro y 850 comandos
La sesión completa duró de las 12:52, cuando se abrió la primera conexión WebSocket desde la IP 172.236.12[.]17, hasta las 21:50, momento en que el atacante desplegó un listener estilo asyncssh contra un VPS propio. En esas nueve horas lanzó más de 850 comandos interactivos, sin usar herramientas ofensivas públicas reconocibles y escribiendo sus scripts sobre la marcha. Todo acabó en una única invocación de Python3 en segundo plano que cogía la credencial, bajaba la clave SSH desde Secrets Manager, la escribía en disco y se autenticaba contra el bastión de una vez. Ningún framework agéntico implicado.
"La IA puede estar cambiando la economía de los ataques — más objetivos, menos tiempo hasta la explotación, menos trabajo manual en tareas repetitivas —, pero todavía no ha reemplazado al atacante con oficio que sabe construir desde cero y evitar trampas", resume Sysdig.
Redis sin contraseña y XMRig
En paralelo, Hunt.io ha publicado los detalles de una campaña de criptominería que ha comprometido 3.562 servidores Redis, probablemente tras un barrido de hosts candidatos en el puerto 6379. El kit lanza tres pipelines a la vez: descubrimiento de objetivos WordPress, inyección de claves en authorized_keys mediante el modo append-only (AOF) de Redis y sondeo de escapes del sandbox Lua contra tres hosts concretos. El método que funciona a escala es el comando SLAVEOF para colar contenido controlado por el atacante y acabar desplegando un minero XMRig.
Las víctimas confirmadas van de Redis 2.8.17 (2015) a 7.2.0 (2023) y de RHEL/CentOS 6 ya sin soporte a kernels Ubuntu actuales: el problema es la falta de autenticación, no un fallo de una versión concreta. De los 2.810 intentos de inyección de claves SSH y escape del sandbox de MongoDB no salió nada, y la cadena completa de credenciales WordPress a webshell se recuperó pero no se confirmó a escala. Hunt.io no atribuye la campaña a ningún grupo conocido.
A esto se suma Operation CameraSwarm, que según el mismo análisis ha comprometido más de 14.000 cámaras IP Dahua mediante fuerza bruta y dos bypasses de autenticación, CVE-2021-33044 y CVE-2021-33045. El patrón se repite: fallos conocidos, sin parchear y expuestos a internet.
Para quien administra sistemas, lo accionable está en dos sitios. Uno, cualquier despliegue de Marimo con el endpoint /terminal/ws accesible y sin actualizar. Dos, los Redis que escuchan en 6379 sin contraseña, que llevan una década siendo el mismo agujero y siguen dando de comer a las botnets de minería.
