Los exploits de Anthropic: la clave no es el modelo, sino el retraso en los parches

¿Da miedo que una IA pueda escribir un exploit funcional para Chrome, Safari y Linux? Menos que la pregunta aburrida que hay detrás: cuando aparezca el siguiente, ¿quién lo tendrá en la mano antes de que salga el parche?

Esto es lo que ha pasado. El 27 de octubre, el Frontier Red Team de Anthropic publicó un artículo de investigación en el que explicaba que, en los últimos meses, un modelo de investigación interno aún sin lanzar había encontrado vulnerabilidades críticas en navegadores y sistemas operativos. Según The Hacker News, el modelo encadenó fallos para crear exploits de prueba de concepto funcionales para Chrome, Safari, Android, Windows y Linux. Esos exploits se construyeron en el laboratorio tras recibir instrucciones, no se han visto en ataques reales, y cada fallo se notificó antes al fabricante, así que todos están ya parcheados.

Un caso muestra cómo es el asunto en la práctica. El error de Linux, CVE-2026-98432, es un use-after-free en el handshake de TCP que existe desde Linux 4.4. Frandroid cuenta que, tras una primera instrucción de un investigador, el modelo escribió un exploit remoto con acceso root: 48 minutos para filtrar una dirección del kernel y cinco más para hacerse con el control.

La habilidad es el titular, pero no la historia

Que los modelos encuentren errores ya no sorprende. Lo que cambia es la economía. A un fallo que lleva en el kernel de Linux desde 2016 se le sacó un exploit remoto con root funcional en menos de una hora de tiempo de modelo. Creemos que el recurso escaso en el ataque solía ser el tiempo de personas expertas, y esa escasez se está erosionando.

La divulgación de Anthropic muestra además su propia contención, algo que merece reconocimiento. La compañía no publicó su exploit, avisó antes a los fabricantes y asegura que colabora con empresas de seguridad externas para clasificar y validar los hallazgos. Frandroid señala que, a 30 de octubre, no se había notificado ninguna reproducción independiente. Aun así, unos cuarenta repositorios de GitHub ya mencionan el fallo, y al menos siete se presentan como pruebas de concepto. Que un laboratorio se contenga no impide que otros construyan su propio exploit a mano o con sus propias herramientas.

El parche no es la meta

A todo el mundo le encanta la frase de que ya están todos parcheados. Nosotros iríamos con cuidado. La corrección de Linux fueron cuatro líneas, escritas el 5 de octubre y presentes en los kernels estables el 11 y el 15. Sin embargo, la mañana del 2 de noviembre, según Frandroid, Ubuntu seguía marcando su corrección como «en curso» para las versiones 22.04 a 26.10, aunque ya había paquetes parcheados referenciados en su página de seguimiento. Red Hat no empezó a distribuir sus correcciones hasta el 1 de noviembre y elevó la gravedad a crítica el 30 de octubre, después de que ella y otros fabricantes hubieran valorado inicialmente el error entre 5,9 y 8,1.

Esa es la verdadera brecha. Escribir el exploit le llevó a un modelo menos de una hora, mientras que la clasificación, la puntuación de gravedad, el empaquetado y el reinicio de tu servidor siguen yendo a velocidad humana y burocrática. Red Hat ha advertido de que las empresas asiáticas tienen que parchear más rápido ante las amenazas de la IA. Nosotros lo extenderíamos a todo el mundo. Si un modelo puede acelerar la explotación, la defensa que importa es acelerar la corrección y el despliegue.

Quién lo tenga primero lo decide todo

Anthropic no ha lanzado este modelo, lo cual tranquiliza y, sospechamos, también es algo temporal. La cuestión es si los defensores tendrán herramientas equivalentes antes que los atacantes. Aquí nos inclinamos por un optimismo cauto: un laboratorio que notifica los fallos a los fabricantes antes de publicarlos hace un favor a quienes defienden. Pero solo funciona si los fabricantes pueden absorber el volumen. Una avalancha de informes críticos bien validados puede desbordar a un equipo pequeño de mantenedores tanto como lo haría un ataque.

Hay también un ángulo político que conviene mirar con ojo escéptico. Radio France recuerda que laboratorios de modelos cerrados como Anthropic han pedido regulación, lo que podría favorecer su modelo de negocio frente a los abiertos. En nuestra opinión, la capacidad ofensiva es un argumento conveniente para esa agenda. Puede ser sincero y, aun así, interesado.

Qué hacer el lunes

Nuestra recomendación es práctica, no apocalíptica. Trata el «parche disponible» como un detonante de emergencia, no como una tarea para el próximo trimestre. Si gestionas servidores Linux, comprueba el estado real de tu kernel, incluidas las variantes de nube y HWE, y reinicia tras actualizar; los contenedores comparten el kernel del anfitrión. Cuando aún no haya corrección, las mitigaciones que enumera Frandroid (filtrar paquetes TCP con opciones IPv4 y desactivar MPTCP) reducen la exposición, aunque Red Hat afirma que solo un kernel parcheado lo soluciona.

El veredicto: no te asustes por el modelo, asústate un poco por tu ritmo de actualizaciones. El próximo error crítico probablemente llegará más rápido que el anterior, y ganarán quienes acorten el tiempo entre que existe una corrección y que esa corrección está en marcha.