La era del embargo de seguridad se acabó
Hay una wea que me tiene pensando bastante últimamente, y es que el modelo entero de cómo manejamos vulnerabilidades en open source se acaba de romper. No en teoría. En la práctica. Con datos reales y timelines que te dejan frío.
Anil Madhavapeddy, mantenedor de OCaml y cohttp (una librería HTTP que usa harta gente), publicó un fix de seguridad esta semana. Un path traversal, nada exótico. El reporte llegó privado por Slack desde Jane Street. Hasta ahí todo normal: lo arreglas privado, avisas a los afectados, publicas el advisory. El problema es lo que pasó después.
Antes de siquiera mirar el patch en detalle, Anil le apuntó su propio agente de IA al código afectado. DeepSeek V4 Pro le encontró varios issues relacionados en segundos. Y después, en menos de un minuto, el agente generó un exploit funcional contra un servidor local. Un minuto. Ni siquiera tuvo que esperar el parche público para tener el arma.
Diez minutos. Esa es tu ventana ahora.
Cuando Anil abrió el PR público en GitHub para que más ojos revisaran el fix, pasaron diez minutos antes de que su servidor web empezara a recibir probes automatizados buscando exactamente el patrón del bug. Diez. No horas, no días. Alguien (o algo) está monitoreando repositorios públicos en tiempo real, y cuando ve un fix de seguridad, lanza el ataque automático.
Y si te parece poco, hay un dato que te cambia el paradigma completo: el tiempo medio de explotación ahora es de -7 días. El signo negativo no es un error de tipeo. Significa que la explotación ahora precede al parche. En 2018-2019 ese mismo métrico era de 63 días. Cruzó el cero en 2024. Estamos en 2026 y la brecha sigue creciendo.
Un CVE description le basta a GPT-4 para explotar el 87%
Fang et al. publicaron un estudio que es el que pone los números sobre la mesa: cuando le das a un agente GPT-4 la descripción de un CVE, explota el 87% de las vulnerabilidades en un benchmark de 15 bugs. Sin la descripción, solo logra el 7%. O sea, no necesitas el código del exploit. No necesitas el PoC. Necesitas literalmente saber de qué trata el bug, y la IA hace el resto.
Esto destruye el modelo de embargo de seguridad que usamos hace años. El supuesto era: mantienes el bug secreto, das tiempo a los maintainers para arreglar, publicas todo coordinado. Pero ahora, si alguien pregunta en una lista de correo algo raro sobre path normalization, o hace un commit raro en un branch huérfano, eso es suficiente señal para que un agente de IA encuentre el exploit. El rumor del bug es el exploit.
Y los maintainers? Trabajando con las manos atadas
Aca es donde me da rabia. Los modelos frontier como Claude Mythos tienen bloqueos de seguridad que les impiden a los maintainers usarlos para auditar su propio código. Anil quería usar Claude Fable para investigar el bug y se negó en redondo porque no tiene acceso a Project Glasswing (el programa de acceso ampliado de Anthropic). 150 organizaciones, 15 países, pero el mantenedor promedio de open source sigue fuera. Mientras tanto, DeepSeek V4 Pro le entregó los resultados sin problema.
O sea: los atacantes tienen acceso a modelos que generan exploits en segundos, y los defensores no tienen acceso a las mismas herramientas para defenderse. La asimetría es brutal.
Qué hacemos entonces
Anil propone tres caminos y yo coincido con básicamente todos: primero, desarrollar fixes en privado de verdad (los private forks de GitHub no funcionan bien para proyectos multi-repo). Segundo, shippear continuamente: parchar rápido, liberar rápido, automatizar el release pipeline. Tercero, protección proactiva en el protocolo: si sabes que el bug es un path traversal con percent-encoding, deploya una regla de mitigación antes de tener el fix completo. Cloudflare lo hizo con Log4Shell en 2021. En open source no tenemos ese CDN centralizado, pero necesitamos algo equivalente.
Mi opinión personal: creo que el concepto de «bugonomics» que cita el artículo (un paper de Pesoli et al. de mayo 2026) es el marco correcto. El bottleneck ya no es encontrar el bug. Es la capacidad de los defensores de validar, priorizar y liberar fixes. Los LLMs están generando exploits felices, pero nuestra capacidad de responder no está mejorando al mismo ritmo. Y eso, para alguien que mantiene infraestructura como yo con los VPS y los servicios, es un problema que duerme conmigo.
La pregunta no es si los modelos frontier, los open weights o el análisis de programas «ganan». La pregunta es cómo orquestamos todo eso para que la poca capacidad humana que queda vaya a fixes durables y no a buscar agujas en pajarés que un agente puede encontrar en un minuto.
Si eres de los que mantiene software open source, cachai que esto cambia las reglas. El embargo ya no te protege. El secreto ya no te compra tiempo. Y el que tiene el agente más rápido, gana. La pregunta es de qué lado quieres estar.
Fuente de inspiración: Just a rumour of a bug is enough to find a security exploit these days
