El rumor basta: cuando la IA encuentra el exploit antes que el parche

El rumor basta: cuando la IA encuentra el exploit antes que el parche

El rumor basta: cuando la IA encuentra el exploit antes que el parche

Resulta que ya no necesitas un PoC público para que alguien empiece a atacar tu software. Solo necesitas que alguien sospeche que hay un bug. Eso es todo. Un rumor, un comentario en un canal de Slack, un commit raro en una rama huérfana, y ya un agente de IA está generando el exploit en menos de un minuto.

Lo que pasó con cohttp

Anil Madhavapeddy, mantenedor del paquete cohttp de OCaml, publicó un fix de seguridad para un path traversal. El procedimiento normal sería: arreglarlo en privado, avisar a los afectados, y después publicar el advisory. Pero esta vez, diez minutos después de abrir el PR público en GitHub, su servidor ya estaba recibiendo probes con el patrón exacto del bug. Diez minutos. Ni siquiera había un proof-of-concept público.

Lo más perturbador: Anil dice que él mismo usó un agente de IA (DeepSeek V4 Pro, porque Claude Fable se negó por sus bloqueos de seguridad) para encontrar el exploit en menos de un minuto. Si a él le tomó un minuto crear el ataque local, diez minutos para que aparezcan probes automatizados parece mucho tiempo.

Los embargos de seguridad ya no sirven

El modelo tradicional de seguridad en open source se basa en embargos: mantienes el bug en secreto mientras lo arreglas, y la secrecy te protege. Pero hoy, si un agente de IA solo necesita una dirección vagamente correcta para encontrar el exploit por su cuenta, el secreto no protege nada. El paper de Fang et al. muestra que cuando le das a un GPT-4 la descripción del CVE, explota el 87% de las vulnerabilidades. Sin la descripción, solo el 7%. La diferencia entre saber y no saber es brutal.

Y los tiempos se comprimieron brutalmente. En 2018-19, el tiempo medio hasta la explotación era de 63 días. En 2024 cruzó cero. Ahora es negativo: la explotación ocurre antes que el parche. marimo’s CVE-2026-39987 pasó de advisory a primer intento de explotación en 9 horas. Langflow’s CVE-2026-33017 en 20 horas. Sin PoC público. Sin nada.

El problema de los mantenedores

Acá es donde se pone complicado para nosotros los que administramos infraestructura o mantenemos proyectos open source. Los modelos frontier (los mejores) tienen bloqueos de seguridad que les impiden generar exploits. Pero los modelos open-weight no. Y los mantenedores pequeños no tienen acceso a Project Glasswing, el programa de Anthropic que da acceso a modelos sin restricciones a 150 organizaciones en 15 países. El mom and pop maintainer está en desventaja total: los atacantes tienen acceso a agentes sin restricciones, y los defensores no.

Un paper de mayo 2026 acuñó el término bugonomics y argumenta que el cuello de botella se movió: ya no es encontrar el bug, sino la capacidad del defensor de priorizar, validar y publicar fixes. Los LLMs generan exploits felices, pero nuestra capacidad de defender no mejora al mismo ritmo porque los mantenedores son humanos con tiempo limitado.

Mi opinión

En la pega yo veo cosas parecidas, aunque a otra escala. Cuando administras VPS y te llegan alerts de CVEs nuevos, la ventana de tiempo para parchear se está cerrando cada vez más rápido. Antes podías esperar al fin de semana para aplicar un update crítico. Hoy, con agentes de IA escaneando repos públicos en tiempo real, esa ventana puede ser de horas, no días.

Lo que me preocupa de verdad no es que la IA encuentre bugs — eso en realidad es bueno si lo usas para defender. Lo que me preocupa es la asimetría. Los atacantes tienen modelos sin restricciones corriendo 24/7 escaneando todo lo que se mueve en GitHub. Los defensores, especialmente en proyectos pequeños, están con las manos atadas. Y los embargos de seguridad, que eran la herramienta principal para ganar tiempo, simplemente ya no funcionan.

La solución no es obvia._shipar continuamente como hace Chrome (dos releases por semana) funciona si eres Google con un solo binario. Pero en el mundo OSS, donde las librerías se embeben en cientos de productos downstream con sus propios ciclos de release, es un nightmare logístico. Lo único claro es que el modelo de seguridad de open source necesita un rediseño urgente, y que los mantenedores necesitan acceso a las mismas herramientas que los atacantes ya tienen.

Fuente de inspiración: Just a rumour of a bug is enough to find a security exploit these days

Comentarios

Aún no hay comentarios. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *