Falla crítica en Marimo: el notebook de Python que usan miles de data scientists ya está siendo explotado activamente

Si usas Marimo para tus notebooks de Python, cierra lo que estás haciendo y actualiza ahorita mismo. No es exageración, no es clickbait: hay una falla crítica con CVSS 9.3 que ya se está explotando activamente en la vida real, y los atacantes tardaron menos de 10 horas en encontrarla desde que se publicó el aviso.

Qué es Marimo y por qué debería importarte

Marimo es un notebook de Python de nueva generación que se ha vuelto muy popular entre data scientists, investigadores y devs que trabajan con IA y machine learning. A diferencia de Jupyter, Marimo es reactivo: los cambios en una celda se propagan automáticamente. Tiene interfaz web, soporte para apps interactivas y se puede correr como servidor. Eso último es exactamente lo que lo pone en el centro de este pedo.

Si estás corriendo Marimo expuesto en red (en un servidor de la empresa, en la nube, en un VPS), esta vulnerabilidad te convierte en blanco inmediato.

El bug: una puerta trasera que nadie bloqueó

Endor Labs publicó el análisis técnico completo y la falla es de esas que duelen leer porque es brutalmente simple.

Marimo tiene un endpoint WebSocket en /terminal/ws que abre una terminal PTY interactiva completa. El problema: ese endpoint no valida autenticación. Ninguna. Todos los demás endpoints de WebSocket sí llaman a WebSocketConnectionValidator.validate_auth(), pero el de la terminal simplemente checaba si el servidor estaba en modo edición y si la plataforma soportaba PTY. Si ambas condiciones se cumplían, te daba shell.

El flujo del ataque es así de simple:

1. Abres conexión WebSocket a ws://[host]:[puerto]/terminal/ws
2. El servidor acepta sin pedir credenciales
3. El servidor te asigna un proceso de shell con PTY
4. Ya tienes ejecución remota de código como el usuario que corre Marimo

No necesitas exploit elaborado. No necesitas encadenar vulnerabilidades. Un cliente WebSocket básico y ya. Es lo que el CVE llama “pre-auth RCE”, y con un CVSS de 9.3 es de las fallas más graves que puedes tener en un servidor.

De la divulgación a la explotación: 9 horas y 41 minutos

Aquí es donde la cosa se pone seria. Sysdig Threat Research Team documentó la explotación en tiempo real con una línea de tiempo que está una chimba de alarmante:

Evento	Hora (UTC)
Advisory publicado	8 abr 2026, 21:50
Primer intento de explotación	9 abr 2026, 07:31
Tiempo total de ventana	9h 41min
Robo de credenciales completado	9 abr 2026, 07:43-07:45
Segunda visita del atacante	9 abr 2026, 08:57

Lo más preocupante: no existía un proof-of-concept público en ese momento. El atacante leyó el advisory, entendió la falla y construyó su propio exploit. El análisis de Sysdig identificó la IP 49.207.56.74 (infraestructura en India, probablemente VPN o proxy), y registró que el operador trabajó de forma manual: exploró directorios, identificó el usuario, buscó archivos .env con llaves de AWS y secretos de aplicación.

No fue un bot automatizado. Fue un wey sentado construyendo su exploit mientras la mayoría aún no sabía del CVE.

Adicionalmente, 125 IPs adicionales fueron detectadas haciendo reconocimiento HTTP y de puertos, aunque no todas llegaron a explotar el WebSocket. De los 186 endpoints de Marimo expuestos en internet que Sysdig probó, 30 (el 16%) completaban el handshake vulnerable. Uno de cada seis.

Versiones afectadas y la corrección

• Vulnerables: Marimo hasta 0.20.4 inclusive
• Parcheado: Marimo 0.23.0 (el fix agrega la llamada que faltaba a validate_auth() en el endpoint del terminal)

El comando para actualizar es directo:

pip install --upgrade marimo

O si quieres pinear la versión segura específica:

pip install "marimo>=0.23.0"

Si usas Poetry, Conda o cualquier otro gestor de entornos, actualiza desde ahí. Lo importante es salir de cualquier versión anterior a 0.23.0.

Checklist: qué hacer si corres Marimo

Urgente (hazlo ahorita)

• Verifica tu versión actual: pip show marimo | grep Version
• Si estás en cualquier versión menor a 0.23.0, actualiza ya
• Después de actualizar, reinicia el servidor de Marimo
• Rota TODAS tus credenciales: llaves de AWS, tokens de API, variables de entorno en archivos .env, secrets de base de datos
• Revisa los logs del servidor buscando conexiones WebSocket a /terminal/ws desde IPs externas

Si no puedes actualizar inmediatamente

• Bloquea el acceso al endpoint /terminal/ws en tu firewall o proxy reverso (nginx, Apache, Cloudflare)
• Asegúrate de que Marimo no esté expuesto directamente en red pública
• Pon Marimo detrás de autenticación a nivel de infraestructura (VPN, auth básica en nginx)
• Deshabilita el terminal integrado si no lo necesitas

Verificación de compromiso

Busca en tus logs estas señales de alerta:

• Conexiones WebSocket a /terminal/ws desde IPs desconocidas
• Comandos de reconocimiento ejecutados (listado de directorios, id, whoami, env)
• Accesos a archivos .env en las rutas de tu proyecto
• Comandos con delimitadores raros tipo echo '---POC-START---'

Si encuentras cualquiera de esas señales, asume compromiso total y empieza por rotar credenciales y revisar qué datos pudieron haber sido exfiltrados.

Por qué esto afecta especialmente a data scientists y devs de IA

Marimo no es una herramienta de sysadmin de red. The Hacker News documentó que la falla se explotó activamente en entornos donde los atacantes fueron directamente por archivos .env con llaves de AWS. Y eso tiene mucho sentido: los data scientists y devs que usan Marimo típicamente tienen acceso a:

• APIs de modelos de IA (OpenAI, Anthropic, Google)
• Buckets de S3 con datos de entrenamiento
• Bases de datos con información sensible
• Pipelines de MLOps en producción

Si te llegan a robar esas credenciales, el daño puede ser mucho mayor que en una máquina normal. Un atacante con tus llaves de AWS puede escalar a toda tu infraestructura en la nube.

Si estás corriendo modelos locales con Ollama o similares, nuestra guía para correr IA local de forma segura te da contexto de las mejores prácticas de aislamiento para herramientas de desarrollo.

El contexto más amplio: las herramientas de dev son el nuevo vector

Esta falla no es un caso aislado. Hay un patrón claro en 2026: los atacantes van contra herramientas del stack de desarrollo porque es donde hay menos controles de seguridad y más credenciales jugosas. Jupyter, VS Code Server, herramientas de MLOps, notebooks en la nube: todo lo que tenga una interfaz web y credenciales almacenadas es objetivo.

Esto es diferente al FortiClient CVE (CVE-2026-35616) que salió esta semana, que va dirigido a sysadmins de red corporativa. El CVE de Marimo afecta a un perfil completamente distinto: data scientists, investigadores, devs de Python que probablemente no tienen un SOC monitoreando sus entornos de trabajo.

Si usas herramientas de IA para programar, como mencionamos en nuestra comparativa de Claude Code vs Cursor vs Copilot, el entorno de desarrollo se está convirtiendo en parte de la superficie de ataque que tienes que proteger.

La neta

Actualiza Marimo. El fix ya existe, es gratis y tarda menos de un minuto. No hay excusa para seguir expuesto. Y si ya tienes versiones anteriores corriendo en servidores, revisa logs antes de dormirte hoy.

La velocidad a la que se explotó esta falla (menos de 10 horas, sin PoC público) confirma lo que la comunidad de seguridad lleva tiempo advirtiendo: el tiempo entre disclosure y explotacion ya no se mide en semanas. A veces ni en dias.

¿Ya la actualizaste? ¿O descubriste algo raro en tus logs? Cuentanos abajo.

Fuentes

• The Hacker News: Marimo RCE Flaw CVE-2026-39987 Exploited Within 10 Hours
• Endor Labs: Root in One Request - Marimo’s Critical Pre-Auth RCE
• Sysdig: Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours
• SecurityWeek: Critical Marimo Flaw Exploited Hours After Public Disclosure
• BleepingComputer: Critical Marimo pre-auth RCE flaw now under active exploitation