Explotación rápida de CVE-2026-39987 en Marimo y campaña masiva de Redis para minar XMRig

Dos investigaciones recientes —una de Sysdig y otra de Hunt.io— subrayan que la separación entre descubrir una vulnerabilidad y explotarla se ha reducido drásticamente: no solo las herramientas basadas en inteligencia artificial aceleran ataques, sino que operadores humanos altamente duchos pueden moverse al mismo ritmo y con gran sigilo. Sysdig documenta una intrusión donde, tras explotar una vulnerabilidad en Marimo (reportada como CVE‑2026‑39987), un atacante logró desde una conexión WebSocket una cadena de pivotes que le permitió recuperar una clave privada de AWS Secrets Manager y autenticarse por SSH a un bastión en cuestión de segundos. Paralelamente, Hunt.io describe una campaña masiva de cryptominería que ha comprometido miles de instancias Redis mediante replicación maliciosa y otras técnicas de persistencia.

Hechos confirmados: Sysdig reportó la explotación activa de CVE‑2026‑39987 en Marimo, con un actor que consiguió una shell interactiva y, usando credenciales obtenidas en la máquina comprometida, llamó a AWS Secrets Manager para recuperar una clave privada y conectarse por SSH a un bastión. Según el registro que Sysdig publicó, el operador tardó apenas ocho segundos en pivotar desde la vulneración inicial hasta la autenticación SSH en el bastión. Hunt.io confirmó la compromisión de 3.562 servidores Redis expuestos en Internet, usando principalmente la replicación (comando SLAVEOF/REPLICAOF) para inyectar payloads que despliegan XMRig.

Información estimada o todavía incierta: no hay atribución pública y fiable sobre qué grupo está detrás de las intrusiones; tampoco está completamente claro el alcance final de las posibles exfiltraciones realizadas tras el acceso al bastión ni si hubo acceso posterior a cuentas AWS adicionales. Sysdig afirmó que el operador no usó agentes de IA y que las herramientas fueron escritas “a mano” durante la sesión; esa afirmación se basa en telemetría y análisis de tácticas, técnicas y procedimientos, pero la posibilidad de que el atacante haya empleado herramientas automatizadas fuera de la sesión observada no puede descartarse.

Técnicamente, la cadena de ataque descrita por Sysdig sigue este patrón: explotación preautenticada de la funcionalidad de terminal WebSocket expuesta por Marimo para obtener ejecución remota; búsqueda y extracción de credenciales locales (archivos de configuración o variables de entorno) que permitieron llamar a AWS Secrets Manager y recuperar una clave privada; escritura de esa clave en disco y autenticación por SSH al bastión. El vector clave aquí es que una aplicación con un endpoint interactivo WebSocket exponía una superficie que, una vez vulnerada, daba acceso a credenciales en el propio host. En el caso de Redis, la técnica que funcionó a escala fue usar SLAVEOF para inducir al servidor objetivo a replicar datos controlados por el atacante; ese contenido puede terminar en el archivo AOF y, con suficientes condiciones, inyectar claves SSH u otros artefactos persistentes. Para detalles sobre el comando de replicación de Redis, consulte la documentación oficial en redis.io.

Quiénes resultan afectados: organizaciones que ejecutan Marimo sin parches o con configuraciones que exponen el endpoint de terminal WebSocket en Internet; cuentas y sistemas en AWS que almacenan secretos accesibles desde instancias vulneradas; servidores Redis expuestos en el puerto 6379 sin autenticación o con ACLs débiles; sitios WordPress desactualizados que pueden ser identificados por barridos automatizados. La variedad de víctimas —desde servidores antiguos hasta kernels recientes, según Hunt.io— muestra que el vector no depende tanto de versiones específicas como de configuraciones inseguras o servicios expuestos innecesariamente.

Las consecuencias prácticas son tangibles: acceso atestiguado a bastiones SSH (bloque de control crítico de la infraestructura), robo de claves privadas desde Secrets Manager (riesgo de movimiento lateral y escalada), despliegue de mineros XMRig que consumen recursos y elevan costes operativos, y potencial despliegue de puertas traseras persistentes. A nivel organizativo, estas intrusiones pueden traducirse en interrupciones de servicio, costos por abuso de cloud y riesgo de que se utilicen accesos comprometidos para acciones más dañinas (exfiltración, destrucción de datos, ransomware).

Qué debe hacer el lector (medidas concretas y priorizadas):

1) Parchee y reduzca la superficie. Actualice Marimo y cualquier otro software con endpoints interactivos; aplique parches tan pronto como estén disponibles y bloquee el acceso externo a endpoints de administración. Si no puede parchear de inmediato, restrinja el acceso mediante listas de control de acceso y firewalls.

2) Segmentar y endurecer el acceso a bastiones. Limite las IPs que pueden acceder al bastión, obligue a autenticación multifactor, y considere usar mecanismos de sesión gestionada (por ejemplo, AWS Systems Manager Session Manager) en lugar de abrir SSH directo al público. Revise y rote claves privadas potencialmente comprometidas.

3) Minimizar privilegios en Secrets Manager y rotar secretos. Aplique políticas IAM con el principio de menor privilegio: una instancia no debería poder leer secretos que no necesita. Habilite CloudTrail y alertas sobre llamadas GetSecretValue inusuales en AWS; audite accesos y rote secretos si hay indicios de exposición. La guía de AWS sobre Secrets Manager puede consultarse en docs.aws.amazon.com.

4) Proteger Redis y servicios de base de datos expuestos. No exponga Redis al Internet público; habilite autenticación, use ACLs y bind al localhost o a una red privada. Bloquee el puerto 6379 en perímetros públicos y monitorice conexiones de replicación entrantes. Para ataques basados en AOF, tenga políticas de integridad y no permita que procesos externos sobrescriban archivos críticos.

5) Detección y respuesta: instrumente detección para patrones concretos observados: conexiones WebSocket inesperadas a endpoints de terminal, llamadas a Secrets Manager desde instancias que no deberían necesitarlas, creación de ficheros de clave privada en discos efímeros, picos de comandos interactivos y procesos que instalan mineros como XMRig (información sobre XMRig en xmrig.com). Establezca alertas y playbooks de respuesta rápida que incluyan aislamiento de la máquina, captura de volcado y rotación de credenciales.

6) Revisar y endurecer despliegues de WordPress. Desactive XML‑RPC si no se usa, mantenga plugins y núcleo al día, y limite la información expuesta que pueda facilitar barridos automatizados.

En conclusión, los casos descritos muestran dos lecciones: primero, la velocidad de explotación puede venir tanto de automatización como de pericia humana; segundo, la vulnerabilidad más explotada no es siempre un fallo técnico puntual sino la combinación de software vulnerable y configuraciones que exponen credenciales y servicios clave. Prevenir significa reducir la exposición, aplicar el principio de menor privilegio y establecer detección temprana específica para cadenas de pivot que impliquen accesos a secrets y a bastiones. Para lecturas y seguimiento de los reportes originales, puede revisar los recursos en las páginas de investigación de Sysdig y Hunt.io: sysdig.com/blog y hunt.io/blog.