El levantamiento de las máquinas comenzó en los servidores de Marimo: una IA lanzó por primera vez un ciberataque autónomo mientras razonaba en un terminal.

Un atacante utilizó un agente de IA basado en un gran modelo de lenguaje tras comprometer un servidor Marimo de acceso público. Según Sysdig, el ataque empezó con la explotación de CVE-2026-39987, y luego derivó en una rápida cadena de acciones: recolección de credenciales en la nube, acceso a AWS Secrets Manager, obtención de una clave SSH privada y conexión a un servidor intermedio desde el cual se accedió a la base de datos interna.

Marimo es un entorno para cuadernos de cálculo interactivos. La vulnerabilidad CVE-2026-39987 permite ejecutar comandos del sistema antes de la autenticación. El fallo afecta a todas las versiones de Marimo hasta la 0.20.4 inclusive, y la corrección se publicó en la versión 0.23.0. Tras la publicación del parche, la vulnerabilidad comenzó a usarse en ataques reales: los investigadores ya observaron reconocimiento manual en cebos y intentos de recopilar datos sensibles.

El incidente que describió Sysdig ocurrió el 10 de mayo de 2026. Tras acceder a una instancia pública de Marimo, el atacante extrajo del entorno dos secretos de cuentas en la nube. Luego usó la clave de AWS obtenida para consultar AWS Secrets Manager y sacó de allí una clave SSH privada.

Unos minutos después esa clave ya se utilizó para acceder al bastión SSH. Así se denomina habitualmente al servidor intermedio por el que administradores o servicios se conectan a sistemas internos cerrados. A continuación el atacante abrió ocho sesiones SSH breves hacia el siguiente servidor y volcó el esquema junto con el contenido completo de la base de datos interna PostgreSQL. La fase con la base duró menos de dos minutos, y toda la cadena de ataque se prolongó algo más de una hora.

La parte principalmente inusual de la historia no es la propia vulnerabilidad de Marimo, sino el comportamiento tras el compromiso. Sysdig considera que las acciones posteriores las ejecutó un agente de IA, y no un script tradicional preescrito. Los investigadores señalaron cuatro indicios que apuntan a un trabajo automatizado con elementos de planificación y adaptación.

El primer indicio es la forma de trabajar con la base de datos. El atacante no contaba con un esquema preparado de antemano, un nombre de aplicación claro en el disco ni un plan listo para un entorno concreto. A pesar de eso, la cadena llevó rápidamente a una tabla con credenciales. El agente no conocía la estructura del sistema por adelantado, pero durante el ataque analizó las pistas encontradas y eligió el siguiente paso.

El segundo indicio está relacionado con un fragmento de planificación que apareció por accidente en el flujo de comandos. Sysdig descubrió una frase en chino con el sentido de «veamos qué más se puede hacer». Apareció durante la búsqueda de credenciales y no parecía formar parte de un conjunto habitual de comandos, sino como una traza de razonamiento o una instrucción intermedia que el agente no debía exponer.

El tercer indicio es el formato de los comandos. Estaban diseñados para que una máquina procesara cómodamente el resultado: los bloques se separaban con un marcador especial, la salida se limitaba en volumen, se desactivó el paginado y se descartó el flujo de errores para no añadir ruido innecesario. Ese estilo se parece más a un diálogo entre herramientas que al trabajo habitual de una persona en un terminal.

El cuarto indicio es la transferencia de valores encontrados de un paso a otro. Por ejemplo, el agente primero comprobaba la existencia del archivo con la clave SSH necesaria y luego mostraba su contenido. En otro caso utilizó datos de un archivo con parámetros de conexión a PostgreSQL y los incorporó a acciones posteriores. Según Sysdig, ese encadenamiento indica un sistema que lee su propia salida previa y construye la siguiente petición en base a ella.

Para los defensores este escenario es problemático porque el agente de IA no tiene que disponer de una instrucción preparada para una red concreta. Un script convencional suele fallar si no encuentra el archivo esperado, el esquema de la base o la contraseña válida. El agente puede detectar la discrepancia, elegir otro camino y continuar el ataque. En ese modo la limitación no es escribir un conjunto distinto de comandos para cada objetivo, sino el coste y el tiempo de ejecución del modelo.

Sysdig describe este ataque como un ejemplo de un nuevo problema práctico. Si un atacante obtiene acceso inicial, un agente de IA puede entender rápidamente un entorno desconocido, encontrar secretos útiles, pasar al siguiente sistema y recopilar datos sin trabajo manual prolongado. En este caso el recorrido fue desde el Marimo vulnerable hasta la PostgreSQL interna a través de claves en la nube, AWS Secrets Manager y el bastión SSH.

Se recomienda a los administradores actualizar Marimo a la versión actual, comprobar si existen instancias del servicio accesibles públicamente y revisar todos los entornos donde podrían haberse almacenado secretos. También conviene reemplazar credenciales en la nube, claves de API y claves SSH si existe el riesgo de que hayan quedado en un host comprometido. En incidentes de este tipo es importante considerar como fuga no solo el servidor vulnerable, sino todas las claves que el atacante pudo obtener tras el primer acceso.