La IA encuentra sus vulnerabilidades más rápido de lo que puede parchearlas

Esta semana llegaron dos noticias que, analizadas juntas, deberían hacer reflexionar a cualquier equipo de desarrollo y seguridad.
La primera, la más importante: Anthropic anunció Claude Mythos Preview, un nuevo modelo de IA que considera demasiado peligroso para publicar abiertamente. ¿El motivo? Es extraordinariamente bueno encontrando vulnerabilidades de seguridad. No estamos hablando de ejemplos triviales en competiciones de CTF. Mythos encontró un bug de 27 años de antigüedad en OpenBSD, uno de los sistemas operativos más reforzados del planeta en materia de seguridad. Encontró una vulnerabilidad en FFmpeg que las herramientas de testing automatizado habían ejecutado cinco millones de veces sin detectar. Encadenó múltiples vulnerabilidades del kernel de Linux para escalar desde un acceso de usuario ordinario hasta el control total de la máquina. Miles de zero-days en todos los sistemas operativos y navegadores principales, la mayoría sin parchear hasta que Anthropic los reportó.
Anthropic no va a publicar el modelo. En su lugar, ha lanzado el Project Glasswing, ofreciendo acceso a unas 40 organizaciones (entre las que se encuentran algunas de las mayores empresas tecnológicas del mundo) para que analicen y corrijan su propio código. También están aportando 100 millones de dólares en créditos de uso y 4 millones de dólares para fundaciones de seguridad de código abierto.
La segunda historia, más pequeña pero quizás más instructiva: CVE-2026-39987, una vulnerabilidad de ejecución remota de código sin autenticación previa en Marimo, un notebook Python de código abierto muy popular entre los científicos de datos. Puntuación CVSS: 9,3. La vulnerabilidad estaba en un endpoint WebSocket (/terminal/ws) que sencillamente no verificaba la autenticación, a pesar de que todos los demás endpoints WebSocket del código base sí lo hacían. Sysdig desplegó honeypots y observó su explotación a las 10 horas de la divulgación pública. Diez horas.
Lo que estas dos historias tienen en común
El hilo que conecta a Mythos con el CVE de Marimo es el mismo: la ventana entre el momento en que existe una vulnerabilidad y el momento en que es explotada se ha reducido al mínimo.
Con Mythos, estamos ante una IA capaz de encontrar bugs que investigadores humanos no detectaron durante décadas. Con el caso de Marimo, estamos ante atacantes que armatizan una vulnerabilidad divulgada antes de que la mayoría de los equipos hayan siquiera leído el aviso. Ambos apuntan en la misma dirección: la velocidad de parcheo y el control de la superficie de ataque han dejado de ser disciplinas opcionales. Son una cuestión de supervivencia.
Y lo que me genera más inquietud es esto: el responsable de red teaming de frontera de Anthropic estimó que los modelos de pesos abiertos alcanzarán la capacidad de Mythos para encontrar bugs en un plazo de seis a dieciocho meses. Eso significa que esta capacidad no permanecerá eternamente bloqueada detrás de una vista previa de investigación restringida. Se propagará.
Lo que esto significa para los equipos de desarrollo
Si desarrolla aplicaciones web, APIs o cualquier sistema con una capa WebSocket, el bug de Marimo debería resultarle incómodamente familiar. Un endpoint que omitió la autenticación. Todos los demás lo hacían correctamente. Ese es el tipo de inconsistencia que se cuela en la revisión de código, supera el QA y permanece en producción durante meses.
En nuestro trabajo con PHP y Docker para clientes empresariales, vemos este patrón constantemente. Un equipo añade un nuevo endpoint, lo copia de uno existente, elimina el middleware de autenticación «temporalmente» durante el desarrollo, y lo publica. El resto de la aplicación está perfectamente protegido. Una ruta no lo está. Con eso es suficiente.
Cuando realizamos pruebas de penetración para estudios de videojuegos y plataformas de viajes, buscamos específicamente estas inconsistencias. El endpoint de depuración completamente abierto detrás de un balanceador de carga. El panel de administración que verifica la autenticación pero no la autorización. La API de staging que por error apuntó al DNS de producción. Estos son los bugs de los que están hechas las vulnerabilidades con CVSS 9+, y son exactamente el tipo de fallos a nivel lógico que los modelos de IA de la clase Mythos comenzarán a encontrar a escala.
El ángulo móvil también importa
Si está pensando «esto es un problema del lado del servidor, mi aplicación móvil está bien», reconsidérelo. En nuestros proyectos nativos de iOS y Android, hemos visto aplicaciones que confían en que el servidor gestione toda la validación de seguridad. Si el backend se ve comprometido a través de una vulnerabilidad como CVE-2026-39987, todo lo que la aplicación móvil envía y recibe queda expuesto: tokens de API, datos de usuario, credenciales de sesión.
Lo hemos visto en aplicaciones de salud e IoT donde el cliente móvil almacena datos sensibles localmente y los sincroniza con un backend que el equipo asumía seguro porque «está detrás de un firewall». La vulnerabilidad de Marimo era explotable a través de una única conexión WebSocket sin autenticación. Los firewalls no sirven de nada si la puerta ya está abierta desde dentro de la capa de aplicación.
Los nuevos requisitos de la App Store de Apple para el cumplimiento del SDK de watchOS e iOS 26 también están añadiendo presión de plazos. Los equipos que se apresuran a cumplir esos plazos de abril mientras mantienen seguros sus backends están en exactamente el tipo de situación operativa en la que se omiten las verificaciones de autenticación.
Una cosa que puede hacer ahora mismo
Un paso concreto: audite cada endpoint WebSocket y en tiempo real de su aplicación para verificar la consistencia de la autenticación. No solo «¿requiere la app que el usuario haya iniciado sesión?», sino «¿cada endpoint individual, incluidos los de depuración, terminal, monitorización e internos, aplica realmente la autenticación?».
La vulnerabilidad de Marimo existía porque su endpoint WebSocket de terminal usaba websocket.accept() sin llamar a validate_auth(). Sus otros endpoints sí la llamaban. Esa diferencia, una llamada de función ausente en un único archivo, supuso un RCE previo a la autenticación con CVSS 9,3.
Si pertenece a un equipo que gestiona aplicaciones web o APIs, dedique una hora esta semana a buscar en su código los manejadores de aceptación WebSocket. Revise cada uno. Si usa Starlette, FastAPI, Express con ws o cualquier framework que trate las conexiones WebSocket como una ruta separada del middleware HTTP, probablemente tenga endpoints que eluden su pila de autenticación habitual. Encuéntrelos antes de que lo haga otra persona.
El panorama general
Anthropic está presentando el Project Glasswing como «defensores primero». La idea es dar ventaja a los buenos antes de que las capacidades de la clase Mythos estén ampliamente disponibles. Es una postura razonable, pero también se apoya en una premisa incómoda: la única manera de protegerse contra una IA que encuentra bugs es desarrollarla primero y confiar en parchear más rápido de lo que los atacantes pueden explotar.
De nuestro trabajo en seguridad configurando Cloudflare y Akamai para la protección DDoS en plataformas de viajes a gran escala, ya vivimos en un mundo donde los ataques automatizados se mueven más rápido que los tiempos de respuesta humanos. La diferencia con el descubrimiento de vulnerabilidades asistido por IA es que los ataques no solo serán más rápidos. Serán más inteligentes. En lugar de escaneos de fuerza bruta, se obtendrá la explotación dirigida de fallos lógicos que ninguna regla WAF puede detectar porque el ataque parece una solicitud legítima.
Eso cambia la forma en que se diseñan las defensas. Las reglas estáticas no son suficientes. Se necesita seguridad por capas: autenticación en cada endpoint, segmentación de red adecuada para que un servidor de notebooks comprometido no pueda acceder a la base de datos de producción, y monitorización real, no solo agregación de logs, sino detección de anomalías sobre lo que están haciendo las conexiones WebSocket.
Hemos hablado con nuestros clientes sobre este cambio antes. Esta semana lo ha vuelto mucho menos teórico.
Hacia dónde vamos desde aquí
El sector de la seguridad está a punto de volverse mucho más frenético. Los modelos de IA capaces de encontrar miles de zero-days en una semana obligarán a los responsables de software a estar en un sprint permanente. Los proyectos de código abierto con equipos pequeños, como Marimo, serán los más afectados porque no disponen de los recursos necesarios para parchear a la velocidad que la amenaza exige ahora.
Si su equipo está desarrollando sobre herramientas de ciencia de datos de código abierto, notebooks para desarrolladores o cualquier herramienta interna que fue diseñada para redes de confianza pero que ahora se encuentra cerca de internet, esta es su llamada de atención. Trate cada herramienta de su stack como parte de su superficie de ataque. Parchee de forma agresiva. Y no asuma que, por ser algo «interno», es seguro.
Si todo esto le suena a una conversación que su equipo necesita tener, hablemos.