La vulnerabilidad crítica CVE-2026-39987 (CVSS 9.3) en los notebooks interactivos Marimo, una ejecución remota de código previa a la autenticación a través del endpoint WebSocket del terminal, ha sido incluida en el catálogo CISA KEV con fecha límite de mitigación el 7 de mayo de 2026. Según Sysdig, un operador humano cualificado, utilizando su propio conjunto de herramientas en Python sin ningún agente de IA, recorrió toda la cadena, desde el notebook vulnerable hasta el bastión SSH, en ocho segundos, una velocidad que los investigadores asociaban anteriormente exclusivamente con ataques automatizados. La vulnerabilidad afecta a versiones de Marimo inferiores a la 0.23.0; el parche está disponible. Ya hemos escrito sobre vulnerabilidades en Marimo anteriormente.
Esencia técnica de la vulnerabilidad
Según el aviso de seguridad de GitHub Advisory, CVE-2026-39987 se clasifica como CWE-306, ausencia de autenticación para una función crítica. El endpoint /terminal/ws en Marimo acepta conexiones WebSocket sin comprobación de autenticación, lo que proporciona a un atacante no autenticado un shell interactivo completo (PTY) y la capacidad de ejecutar comandos arbitrarios.
Cabe destacar una discrepancia en los datos sobre las versiones afectadas: el campo del paquete en el aviso de GitHub indica como afectadas las versiones inferiores a la 0.23.0, mientras que la sección detallada del mismo documento menciona Marimo ≤ 0.20.4. La versión 0.23.0 figura como corregida.
Anatomía del ataque: nueve horas, 850 comandos, cero herramientas públicas
Según Sysdig (a través de su investigación), la cadena de ataque se desarrolló de la siguiente forma:
- 18:57:22: se estableció una conexión WebSocket con el endpoint vulnerable
- 18:57:26: se extrajeron las credenciales de AWS del almacén de la aplicación
- 18:57:30: autenticación SSH en el host bastión utilizando una clave privada obtenida de AWS Secrets Manager
Ocho segundos desde la primera conexión hasta el control total del bastión. Según indica Sysdig, el operador utilizó una única invocación de Python3 en segundo plano, que en un solo script extraía las credenciales, obtenía la clave SSH de Secrets Manager, la escribía en disco y se autenticaba en el bastión.
Durante una sesión de nueve horas (de 12:52 a 21:50) el atacante ejecutó más de 850 comandos interactivos sin emplear ninguna herramienta ofensiva pública conocida. Todos los scripts fueron escritos y depurados manualmente directamente en la sesión. Sysdig subraya especialmente que el operador esquivó la trampa en la que caía cada agente de IA autónomo perfilado por ellos al atacar la misma vulnerabilidad.
La fuente de la conexión inicial fue la dirección IP 172.236.12[.]17. Durante la sesión, el atacante desplegó un listener de estilo asyncssh en su propio VPS.
Contexto: la IA acelera los ataques, pero no sustituye la pericia
Este incidente ilustra una tesis importante: aunque las herramientas de IA reducen el tiempo entre el descubrimiento de una vulnerabilidad y su explotación y rebajan la barrera de entrada para atacantes menos cualificados, los operadores experimentados son capaces de actuar a la misma velocidad sin automatización y, al mismo tiempo, eludir los mecanismos de defensa con mayor eficacia. Como señala Sysdig, la IA está cambiando la economía de los ataques (más objetivos, explotación más rápida, menos tareas rutinarias), pero todavía no ha sustituido al atacante cualificado que sabe crear herramientas desde cero y evitar las trampas.
Campañas paralelas: Redis y Dahua
Criptominería a través de Redis
En paralelo a los acontecimientos en torno a Marimo, Hunt.io reveló una campaña de criptominería en la que se comprometieron 3 562 servidores Redis de una lista de 12 966 hosts detectados mediante un escaneo del puerto 6379. Entre los servidores preseleccionados sin autenticación (2 342 hosts), el nivel de compromiso alcanzó el 72,6 %.
Las víctimas utilizaban Redis en versiones desde la 2.8.17 (2015) hasta la 7.2.0 (2023) y Linux desde RHEL/CentOS 6 obsoletos hasta núcleos actuales de Ubuntu. Hunt.io indica que la causa del compromiso masivo fue la ausencia de autenticación, y no una vulnerabilidad de una versión específica de Redis.
El método principal fue el comando SLAVEOF para manipular la replicación (rogue replication), a través del cual se entregaba el minero XMRig al servidor objetivo. De las cuatro técnicas probadas, solo la replicación funcionó a gran escala: la inyección de claves SSH mediante AOF y los intentos de escape de sandbox de MongoDB no dieron resultados en 2 810 intentos. Se detectó una cadena de compromiso de WordPress, pero no se confirmó a escala. La campaña no se ha atribuido a ningún grupo conocido.
Indicadores de compromiso del estudio: direcciones IP 47.250.92[.]230, 34.166.99[.]116, 20.198.10[.]42, 188.245.99[.]156; dominio pool.moneroocean[.]stream.
Operation CameraSwarm
Según el índice del blog de Hunt.io, en el marco de la operación Operation CameraSwarm se comprometieron en 35 días más de 14 530 cámaras IP Dahua en territorio de Ucrania y Rusia. El ataque empleó fuerza bruta y vulnerabilidades de bypass de autenticación CVE-2021-33044 y CVE-2021-33045 (ambas con CVSS 9.8, CWE-287), así como la técnica de retransmisión P2P. Ambas vulnerabilidades de Dahua se incluyeron en el catálogo CISA KEV en agosto de 2024.
Evaluación del impacto
Las organizaciones con mayor riesgo por CVE-2026-39987 son aquellas que utilizan Marimo para cómputo interactivo en entornos en la nube, especialmente cuando existe acceso a AWS Secrets Manager desde la misma instancia. La cadena «WebSocket → credenciales → bastión SSH» demuestra cómo una única vulnerabilidad en una herramienta de trabajo con datos puede conducir a la completa compromisión de la infraestructura en la nube.
La campaña contra Redis subraya la magnitud del problema de las bases de datos expuestas sin autenticación: el 72,6 % de los servidores sin protección fueron comprometidos.
Recomendaciones
- Marimo: actualice inmediatamente a la versión 0.23.0 o superior. Si la actualización no es posible, bloquee el acceso al endpoint
/terminal/wsa nivel de control de red - AWS: audite las instancias en las que se ejecuta Marimo para verificar el acceso a Secrets Manager. Rote las claves SSH y las credenciales de AWS almacenadas en Secrets Manager si la instancia fue accesible desde el exterior
- Redis: habilite la autenticación (
requirepass), limite el acceso de red al puerto 6379, deshabilite el comandoSLAVEOFmedianterename-command - Dahua: actualice el firmware de los dispositivos a versiones que mitiguen CVE-2021-33044 y CVE-2021-33045, cambie las credenciales predeterminadas
- Verifique la presencia de los IOC indicados en los registros de red
El incidente con Marimo es una demostración clara de que las estrategias de defensa diseñadas para detectar ataques automatizados son insuficientes: un operador cualificado puede pasar de una vulnerabilidad al control total en cuestión de segundos, utilizando únicamente su propio código y evitando los indicadores típicos. La prioridad es actualizar Marimo a la versión 0.23.0 y auditar la cadena de acceso desde los notebooks de cómputo hasta los secretos de la infraestructura en la nube.
